CMSC 414 Computer and Network Security Lecture 9

CMSC 414Computer and Network SecurityLecture 9 Jonathan Katz

Non-malleable public-key enc. • RSA-based: OAEP • Diffie-Hellman based

G H PKCS #1 v2.1 (e.g., OAEP) m || 0…0 r 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 • Transferability • Non-repudiation Not obtained by 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? • 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

sk H H(M) Sign  M 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

Crypto pitfalls and recommendations

Crypto pitfalls? • Crypto deceptively simply • Why does it so often fail? • Important to distinguish various issues: • Bad cryptography, bad implementations, bad design, etc. • Even good cryptography can often be ‘circumvented’ by adversaries operating ‘outside the model’ • Even the best cryptography only shifts the weakest point of failure to elsewhere in your system • 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

CMSC 414 Computer and Network Security Lecture 9