Pkcs Pkcs 1 Pkcs 1 Pkcs 1 Pkcs 1

INFS 766 PKCS 1 Internet Security Protocols

v Specifies how to use the RSA Lecture 10 algorithm securely for encryption PKCS and signature v Why do we need this? Ø Padding for encryption Ø Different schemes for signature Prof. Ravi Sandhu

PKCS PKCS 1

v Public-key cryptography standards (PKCS) v Chosen ciphertext attack based on v Owned by RSA and motivated to promote multiplicative property of RSA RSA Ø Attacker wishes to decrypt c v Created in early 1990’s Ø Choose r, compute c’ = c.re mod n v Numbered from PKCS1 to PKCS15 Ø Get victim to decrypt c’ giving cd.r mod n v Some along the way have Ø cd.r.r -1 mod n = cd mod n Ø lost interest v Padding destroys multiplicative Ø folded into other PKCS property Ø taken over by other standards bodies v Continue to evolve © Ravi Sandhu 2002 2 © Ravi Sandhu 2002 5

PKCS 1 PKCS 1

v RSA Cryptography Standard v Version 1.5, 1993 Ø Version 2.0 onwards (1998) Ø Encryption padding was found defective v RSA Encryption Standard in 1998 by Bleichenbacher Ø Possible to generate valid ciphertext Ø Version 1.5 (1993) without knowing corresponding plaintext with reasonable probability of success (chosen ciphertext)

v Version 2.0, 1998 v Encryption scheme Ø Uses Optimal asymmetric encryption protocol (OAEP) Ø Combines encryption primitive with an encryption by Bellare-Rogoway 1994 encoding method • provably secure in the random oracle model Ø message à encoded message à integer message • Informally, if hash functions are truly random, then an representative à encrypted message adversary who can recover such a message must be able v Decryption scheme to break RSA Ø • plaintext-awareness: to construct a valid OAEP encoded Combines decryption primitive with a decryption message, an adversary must know the original plaintext decoding method Ø PKCS 1 version 1.5 padding continues to be allowed for Ø encrypted message à integer message representative backward compatibility à encoded message à message Ø Accommodation for multi-prime RSA v Original version 1.5 scheme and new version 2.0 • Speed up private key operations scheme

PKCS 1 PKCS 1

v Cryptographic primitives v Signature scheme Ø Combines signature primitive with a signature encoding v Cryptographic scheme method Ø Encryption scheme Ø message à encoded message à integer message Ø Signature scheme representative à signature • Signature with appendix: supported v Decryption scheme • Signature with message recovery: not supported Ø Combines verification primitive with a verification decoding method v Encoding and decoding Ø signature à integer message representative à encoded Ø Converting an integer message into an octet message à message string for use in encryption or signature v Original version 1.5 scheme scheme and vice versa Ø Signature with appendix

PKCS 1 PKCS 1

v Cryptographic primitives v The future Ø Encrypt RSAEP((n,e),m) v Probabilistic signature scheme (PSS) Ø Provably secure in random oracle model Ø Decrypt RSADP((n,d),c) Ø Natural extension to message recovery Ø Sign RSASP1((n,d),m) Ø Verify RSAVP1((n,e),s) v Basically exponentiation with differently named inputs

v Password-Based Cryptography v Version 2.0 adds PBKDF2 Standard Ø Arbitrary length key Ø Version 1.5, 1993 Ø Any underlying hash function, most likely Ø Version 2.0, 1999 with HMAC v Oriented towards protection of Ø Salt not fixed at 8 bytes private keys Ø Provable security in random oracle model v Does not specify a standard for password format

PKCS 5 PKCS 5

v Password-based key derivation function v Encryption schemes Ø Key = PBKDF(passwd, salt, iteration count) Ø PBES1 v salt allows same password to give many • PBKDF1 with DES or RC2 in CBC keys Ø PBES2 • PBKDF2 with some underlying encryption Ø May actually have same password scheme Ø Separate dictionary attack for every salt v MAC scheme v Iteration count controls complexity of dictionary attack Ø PBMAC1 • PBKDF2 with some underlying MAC scheme

PKCS 5 PKCS 10

v Version 1.5 PBKDF1 v Certification Request Syntax Standard Ø Key size limited to 160 bits v Specifies format of unsigned Ø Only MD5 and SHA as underlying hash certificate requested to be signed functions v Does not specify format of returned Ø Assumes key will be used for CBC signed certificate Ø 8-byte salt Ø No security proof

v Version 1.0, 1993 v Private-Key Information Syntax Ø In widespread use Standard v Version 1.5, 1998 Ø Version 1.2, 1993 v Version 1.7, 2000 Ø Minor changes such as references to PKCS 6 replaced by references to X.509v3

PKCS 10 PKCS 8

v CertificationRequestInfo v PrivateKeyInfo Ø version Ø version Ø subjectName Ø privateKeyAlgorithm Ø subjectPublicKeyInfo Ø privateKey Ø attributes Ø attributes

PKCS 10 PKCS 8

v CertificationRequest v encryptedPrivateKeyInfo Ø certificationRequestInfo Ø encryptionAlgorithm Ø signatureAlgorithm Ø encryptedData Ø signature • privateKeyInfo BER-encoded and encrypted v Signed with private key corresponding to v Usually encrypted using PKCS 5 public key in request Ø very RSA specific Ø IETF RFC 2511 defines a different format: certificate request message format

v Personal Information Exchange v The entire stuff is then either Syntax Standard Ø Signed • And accompanied with signing certificate Ø Version 1, 1999 Ø MAC’ed v Builds on PKCS 8 • PKCS 5 based and accompanied with salt v Further evolution PKCS 15 and iteration count v Notice: opposite of usual sequence Ø Encrypt and then authenticate, versus Ø Authenticate and then encrypt

PKCS PKCS 12 DISCONTINUED OR DISINTERESTED

v 6 types of information v PKCS 2 Ø PKCS 8 shrouded key Ø discontinued, incorporated into PKCS 1 Ø Private key Ø Certificates v PKCS 3 • X.509v3 Ø Diffie-Hellman Key Agreement, 1993 • SDSI Ø CRLs v PKCS 4 • X.509 Ø discontinued, incorporated into PKCS 1 Ø Secret • Whatever Ø Recursive composition of these

PKCS PKCS 12 TAKEN OVER BY OTHERS

v Each of these can be v PKCS 6 Ø Plaintext Ø Extended Certificate Syntax Standard Ø Enveloped Ø Taken over by X.509v3 • Encrypted using a secret key which is encrypted using a public key v PKCS 7 Ø Encrypted Ø Cryptographic Message Syntax • Secret key encrypted Standard • Usually password derived Ø Taken over by IETF PKIX CMS – Use PKCS 5 and a password formatting standard which is part of PKCS 12

Crypto Application v PKCS 9 (Browser, email client etc) Ø Selected Attribute Types

Ø For use in PKCS 6, 7, 8, 10 Standard Crypto API (PKCS 11, CSP, etc)

Cryptographic Token Information Format Standard (PKCS 15)

PKCS 11

v PKCS 11 Ø Cryptographic Token Interface Standard Ø API used by Netscape (pre 6.0) Ø Microsoft CSP (Cryptographic Service Provider) is a competitor

PKCS IN DEVELOPMENT

v PKCS 13 (new, in development) Ø Elliptic Curve Cryptography Standard Ø There are IEEE standards, so not clear why v PKCS 14 (new, in development) Ø Pseudorandom Number Generation Standard v PKCS 15 (new, in development) Ø Cryptographic Token Information Format Standard Ø Crypto API neutral