CMSC 414 Computer and Network Security Lecture 7

CMSC 414Computer and Network Security

Lecture 7

Jonathan Katz

Malleability/chosen-ciphertext security All the public-key encryption schemes we have

seen so far are malleable– Given a ciphertext c that encrypts an (unknown)

message m, it is possible to generate a ciphertext c’ that encrypts a related message m’

In many scenarios, this is problematic– E.g., auction example; password example

Note: the problem is not integrity (there is no integrity in public-key encryption, anyway), but malleability

Malleability/chosen-ciphertext security In the public-key setting, security against chosen-

ciphertext attacks is equivalent to non-malleability In general, always use a public-key encryption

scheme secure against chosen-ciphertext attacks!– E.g., RSA PKCS #1 v2.1

When using hybrid encryption, if both components are secure against chosen-ciphertext attacks then the combination it also secure against chosen-ciphertext attacks

Signature schemes

Basic idea A signer publishes a public key pk

– As usual (for now), we assume everyone has a correct copy of pk

To sign a message m, the signer uses its private key to generate a signature

Anyone can verify that is a valid signature on m with respect to the signer’s public key pk– Since only the signer knows the corresponding private key, we

take this to mean the signer has “certified” m

Security (informally): no one should be able to generate a valid signature other than the legitimate signer

Prototypical application Software company wants to periodically release

patches of its software– Doesn’t want a malicious adversary to be able to

change even a single bit of the legitimate path

Solution: – Bundle a copy of the company’s public key along with

initial copy of the software– Software patches signed (perhaps with a version

number)– Do not accept patch unless it comes with a valid

signature (and increasing version number)

Signatures vs. MACs Could MACs work in the previous example?

– Computing one signature vs. multiple MACs– Public verifiability– Transferability– Non-repudiation

Not obtainedby MACs!

Functional definition Key generation algorithm: randomized algorithm

that outputs (pk, sk) Signing algorithm:

– Takes a private key and a message, and outputs a signature; Signsk(m)

Verification algorithm:– Takes a public key, a message, and a signature and

outputs a decision bit; b = Vrfypk(m, )

Correctness: for all (pk, sk), Vrfypk(m, Signsk(m)) = 1

Security? Analogous to MACs

– Except that adversary is given the signer’s public key

(pk, sk) generated at random; adversary given pk Adversary given 1 = Signsk(m1), …,

n = Signsk(mn) for m1, …, mn of its choice

Attacker “breaks” the scheme if it outputs a forgery; i.e., (m, ) with:

• m ≠ mi for all i

• Vrfypk(m, ) = 1

“Textbook RSA” signatures Public key (N, e); private key (N, d) To sign message m ZN

*, compute = md mod N

To verify signature on message m, check whether e = m mod N

Correctness holds…

…what about security?

Security of textbook RSA sigs? Textbook RSA signatures are not secure

– Easy to forge a signature on a random message– Easy to forge a signature on a chosen message, given

two signatures of the adversary’s choice

Hashed RSA Public key (N, e); private key (N, d) To sign message m, compute = H(m)d mod N To verify signature on a message m, check

whether e = H(m) mod N Why does this prevent previous attacks?

Security of hashed RSA Can we prove that hashed RSA is secure?

– Take CMSC456!

Hashed RSA signatures can be proven secure based on the hardness of the RSA problem, if the hash is modeled as a random function

Variants of hashed RSA are used in practice

DSA/DSS signatures Another popular signature scheme, based on the

hardness of the discrete logarithm problem– Introduced by NIST in 1992– US government standard

I will not cover the details, but you need to know that it exists

Hash-and-sign Say we have a secure signature scheme for “short”

messages (e.g., hashed RSA, DSS, …)– How to extend it for longer messages?

Hash and sign– Hash message to short “digest”; sign the digest

Used extensively in practice

H SignM H(M)

sk

Crypto pitfalls

Cryptography is not a “magic bullet”

Crypto can be difficult to get right– Must be implemented correctly– Need expertise; “a little knowledge can be a dangerous

thing…”– Must be integrated from the beginning– Use only standardized algorithms and protocols– No security through obscurity!

Cryptography is not a “magic bullet”

Crypto alone cannot solve all security problems– Key management; social engineering; insider attacks– Develop (appropriate) threat/trust models– Need to analyze weak links in the chain…– Adversary may not be able to eavesdrop, but can it:

• Access your hard drive?• See CRT emissions?• Go through your trash?

– “Side channel attacks” on cryptosystems

Cryptography is not a “magic bullet”

Human factors– Crypto needs to be easy to use both for end-users and

administrators– Important to educate users about appropriate security

practices

Need for review, detection, and recovery Security as a process, not a product

Random number generation Do not use “standard” RNGs; use cryptographic

RNGs instead E.g., srand/rand in C:

– srand(seed) sets state=seed (|state| = 32 bits)– rand():

• state = f(state), where f is some linear function• return state

Generating a 128-bit key using 4 calls to rand() results in a key with only 32 bits of entropy!

More on random number generation

Netscape v1.1:– rv = SHA1(pid, ppid, time)– return rv

Problem: the input to SHA1 has low entropy