Slides for lecture 9

advertisement
CMSC 414
Computer and Network Security
Lecture 9
Jonathan Katz
Non-malleable public-key enc.
 RSA-based: OAEP
 Diffie-Hellman based
PKCS #1 v2.1 (e.g., OAEP)
m || 0…0
r
G
H
e
c =
m1
m2
mod N
Status of OAEP
 Can be proven secure against chosen-ciphertext
attacks based on the RSA assumption and the
assumption that the hash functions G, H are
“truly random”
Other alternatives
 There exist variants of El Gamal encryption that
can be proven secure against chosen-ciphertext
attacks based on the DDH assumption (and no
unrealistic assumptions regarding hash functions)
– Factor of ~2 less efficient than El Gamal
Hybrid encryption
 When using hybrid encryption, if both
components are secure against chosen-ciphertext
attacks then the combination is also secure against
chosen-ciphertext attacks
Recommendations
 Always use authenticated encryption in the
private-key setting
– E.g., encrypt-then-authenticate
 Always use a public-key encryption scheme
secure against chosen-ciphertext attacks!
– E.g., RSA PKCS #1 v2.1
 When using hybrid encryption, combine them!
Signature schemes
Basic idea
 A signer publishes a public key pk
– As usual, 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: no one should be able to generate a valid
signature other than the legitimate signer
Typical 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 patch
 Solution:
– Bundle a copy of the company’s public key with initial
copy of the software
– Software patches signed (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
– Managing one key vs. multiple keys
– Public verifiability
Not obtained
– Transferability
by MACs!
– Non-repudiation
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?
 Note: has the added advantage of handling long
messages “for free”
Security of hashed RSA
 Hashed RSA signatures can be proven secure
based on the hardness of the RSA problem, if the
hash is modeled as a random function
– Proof in CMSC456
 Variants of hashed RSA have been standardized,
and 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 should 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
M
H
H(M)
sk
Sign

Crypto pitfalls
and recommendations
Crypto pitfalls?
 Crypto deceptively simply
– Why does it so often fail?
 Important to distinguish various issues:
1. Bad cryptography, bad implementations, bad design,
etc.
2. Even good cryptography can often be ‘circumvented’
by adversaries operating ‘outside the model’
3. Even the best cryptography only shifts the weakest
point of failure to elsewhere in your system
4. Systems are complex
 Avoid the first; be aware of 2-4
Cryptography is not a “magic bullet”
 Crypto is difficult to get right
– Must be implemented correctly
– Must be integrated from the beginning, not added on
“after the fact”
– Need expertise; “a little knowledge can be a dangerous
thing…”
– Can’t be secured by Q/A, only (at best) through
penetration testing and dedicated review of the code by
security experts
Cryptography is not a “magic bullet”
 Crypto alone cannot solve all security problems
– Key management; social engineering; insider attacks
– Need to develop appropriate threat/trust models for the
system as a whole
 Defense in depth
– Need for review, detection, and recovery
– Security as a process, not a product
Human factors
 Crypto needs to be easy to use both for end-users
and administrators
 Important to educate users about appropriate
security practices
General recommendations
 Use only standardized algorithms and protocols
– No security through obscurity!
 Don’t implement your own crypto
– If your system cannot use “off-the-shelf” crypto
components, re-think your system
– If you really need something new, have it designed
and/or evaluated by an expert
 Don’t use the same key for multiple purposes
– E.g., encryption and MAC; or RSA encryption and
signatures
 Use sufficient entropy when choosing keys
Download