CMSC 414 Computer and Network Security Lecture 7 Jonathan Katz.
-
date post
19-Dec-2015 -
Category
Documents
-
view
217 -
download
2
Transcript of CMSC 414 Computer and Network Security Lecture 7 Jonathan Katz.
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