Public Key Infrastructure tell me in plain English

Public Key Infrastructure – tell me in plain English AND THEN deep technical how PKI works Steve Lamb stephlam@microsoft. com http: //blogs. technet. com/steve_lamb IT Pro Security Evangelist Microsoft Ltd

Objectives Demystify commonly used terminology Explain how PKI works Get you playing with PKI in the lab Make some simple recommendations

Agenda Foundational Concept (level 200) PKI and Signatures (level 330) Recommendations (level 310) Reference material Common Algorithms (level 360)

What can PKI enable? Secure Email – sign and/or encrypt messages Secure browsing – SSL – authentication and encryption Secure code – authenticode Secure wireless – PEAP & EAP-TLS Secure documents – Rights Management Secure networks – segmentation via IPsec Secure files – Encrypted File System(EFS)

Foundational Concepts

Encryption vs. Authentication Encrypted information cannot be automatically trusted You still need authentication Which we can implement using encryption, of course

Assets What we are securing? Data Services (i. e. business etc. applications or their individually accessible parts) This session is not about securing: People (sorry), cables, carpets, typewriters and computers (!? ) Some assets are key assets Passwords, private keys etc…

Digital Security as Extension of Physical Security of Key Assets Strong Physical Security of KA Weak Physical Security of KA Strong Digital Security Weak Digital Security Good Security Everywhere Insecure Environment

Symmetric Key Cryptography Plain-text input “The quick brown fox jumps over the lazy dog” Cipher-text Plain-text output “Ax. Cv; 5 bm. Ese. Tfid 3) f. Gsm. We#4^, sdgf. Mwi r 3: dk. Je. Ts. Y 8 Rs@!q 3 %” “The quick brown fox jumps over the lazy dog” Encryption Decryption Same key (shared secret)

Symmetric Pros and Cons Strength: Simple and really very fast (order of 1000 to 10000 faster than asymmetric mechanisms) Super-fast (and somewhat more secure) if done in hardware (DES, Rijndael) Weakness: Must agree the key beforehand Securely pass the key to the other party

Public Key Cryptography Knowledge of the encryption key doesn’t give you knowledge of the decryption key Receiver of information generates a pair of keys Publish the public key in a directory Then anyone can send him messages that only she can read

Public Key Encryption Clear-text Input “The quick brown fox jumps over the lazy dog” Cipher-text Clear-text Output “Py 75 c%bn&*)9|f. De^ b. DFaq#xzj. Fr@g 5=&n md. Fg$5 knv. Md’rkveg Ms” “The quick brown fox jumps over the lazy dog” Encryption public Recipient’s public key Decryption Different keys private Recipient’s private key

Public Key Pros and Cons Weakness: Extremely slow Susceptible to “known ciphertext” attack Problem of trusting public key (see later on PKI) Strength Solves problem of passing the key Allows establishment of trust context between parties

Hybrid Encryption (Real World) Launch key for nuclear missile “Red. Heat” is. . . Symmetric encryption (e. g. DES) User’s public key (in certificate) Randomly. Generated symmetric “session” key RNG *#$fjda^j u 539!3 t t 389 E *&@ 5 e%32^kd Symmetric key encrypted asymmetrically (e. g. , RSA) Digital Envelope As above, repeated for other recipients or recovery agents Digital Envelope Other recipient’s or agent’s public key (in certificate) in recovery policy

Hybrid Decryption *#$fjda^j u 539!3 t t 389 E *&@ 5 e%32^kd Launch key for nuclear missile “Red. Heat” is. . . Symmetric decryption (e. g. DES) Symmetric “session” key Recipient’s private key Asymmetric decryption of “session” key (e. g. RSA) Digital envelope contains “session” key encrypted using recipient’s public key Digital Envelope Session key must be decrypted using the recipient’s private key

Breaking It on $10 Million Symme-tric ECC Key RSA Key Time to Break Machines Memory 56 112 420 < 5 mins 10000 Trivial 80 160 760 600 months 4300 4 GB 96 192 1020 3 million years 114 170 GB 128 256 1620 10 E 16 years 0. 16 120 TB From a report by Robert Silverman, RSA Laboratories, 2000

PKI and Signatures

Public Key Distribution Problem We just solved the problem of symmetric key distribution by using public/private keys But… Scott creates a keypair (private/public) and quickly tells the world that the public key he published belongs to Bill People send confidential stuff to Bill does not have the private key to read them… Scott reads Bill’s messages

Eureka! We need PKI to solve that problem And a few others…

How to Verify a Public Key? Two approaches: 1. Before you use Bill’s public key, call him or meet him and check that you have the right one Fingerprint or hash of the key can be checked on the phone 2. Get someone you already trust to certify that the key really belongs to Bill By checking for a trusted digital signature on the key But there has to be one… And you have to have friends to trust in first place…

Trust Models Web-of-Trust (PGP) Peer-to-peer model Individuals digitally sign each other keys You would implicitly trust keys signed by some of your friends Trusted Authority + Path of Trust (CAs) Everyone trusts the root Certificate Authority (Verisign, Thawte, BT etc. ) CA digitally signs keys of anyone having checked their credentials by traditional methods CA may even nominate others to be CAs – and you would trust them automatically, too

Trust Models Issues and Future Web-of-trust is more, erh, trustworthy But it is time-consuming, requires lots of work and general public doesn’t understand it CAs tend to be a little bit like a big brother as we all have to trust them implicitly But it is a simpler model, easier to deploy and manage Combination strategy? Let’s trust a CA that verifies keys by traditional strong methods and peer-to-peer recommendations

Creating a Digital Signature Message or File 128 bits Message Digest This is a really long message about Bill’s… Digital Signature Jrf 843 kjfgf* £$&Hdif*7 o Usd*&@: <C HDFHSD(** Py 75 c%bn&*)9|f. De^b DFaq#xzj. Fr@g 5=&n md. Fg$5 knv. Md’rkveg Ms” Hash Function (SHA, MD 5) Calculate a short message digest from even a long input using a one-way message digest function (hash) Asymmetric Encryption private Signatory’s private key

Verifying a Digital Signature Jrf 843 kjf gf*£$&Hd if*7 o. Usd *&@: <CHD FHSD(** Asymmetric decryption (e. g. RSA) Py 75 c%bn&*) 9|f. De^b. DFaq #xzj. Fr@g 5= &nmd. Fg$5 kn v. Md’rkveg. Ms” ? == ? Signatory’s public key Everyone has access to trusted public key of the signatory Are They Same? Same hash function (e. g. MD 5, SHA…) This is a really long message about Bill’s… Py 75 c%bn&*) 9|f. De^b. DFaq #xzj. Fr@g 5= &nmd. Fg$5 kn v. Md’rkveg. Ms” Original Message

Hash (Digest) Functions MD 5 and SHA Just a hash value of between 128 bits (MD 5) and 512 bits of key (SHA 512) Great support in. NET and in Crypto. API of Windows. NET Fx also supports shorter SHAs (160, 256, and 384 bits) Please don’t use (ever) any function with 64 bit (or smaller) result

Message Authentication Codes “MACs” – Typically, combination of a hash function and a symmetric encryption Integrity, authenticity but non-repudiation Must share the key! HMAC Digest + shared-secret encryption for up to 160 bit results MACTriple. DES Encryption using 8, 16 or 24 bytes of Triple. DES key on top of a hash 64 bit result (ouch!) All of the above implemented in. NET Fx Many others exist, notably UMAC

Certificates The simplest certificate just contains: Information about the entity that is being certified to own a public key That public key And all of this is Digitally signed by someone trusted (like your friend or a CA)

X. 509 Certificate Authority Digital Signature of All Components Together: Serial Number Issuer X. 500 Distinguished Name Validity Period Subject X. 500 Distinguished Name Subject Public Key Information Key/Certificate Usage Extensions OU=Contoso… The Key or Info About It

Authentication with Certificates 1. 2. Melinda gets Bill’s certificate She verifies its digital signature She can trust that the public key really belongs to Bill But is it Bill standing if front of her, or is that Scott? 3. Melinda challenges Bill to encrypt for her a phrase etc. she just made up (“I really need more shoes”) 4. Bill has, of course, the private key that matches the certificate, so he responds (“*&$^%£$&£fhsdf*&EHFDhd 62^&£”) 5. Melinda decrypts this with the public key she has in the certificate (which she trusts) and if it matches the phrase she challenged Bill with then it must really be Bill himself! By the way, that’s the basic concept of how SSL works

What’s in the Store? Most certificates are “safe” No need to protect them too much, as they are digitally signed and only contain publicly available information Store anywhere, a file or a “dumb” memory-only smartcard Private keys (and certs that include them) that match the public key are extremely vulnerable It is a Key Asset You must protect them well Store in “Protected Storage” on your OS or a “smart” smartcard that will have crypto functionality on board Axalto’s. NET-enabled smart cards for instance

Word About Smartcards Some smartcards are “dumb”, i. e. they are only a memory chip Not recommended for storing a private key used in a challenge test (verifying identity) Anyway, they are still better than leaving keys on a floppy disk or on the hard drive Cryptographically-enabled smartcards are more expensive but they give much more security Private key is secure and used as needed Additional protection (password, biometrics) is possible Hardware implements some algorithms Self-destruct is possible

Certification Hierarchy Most organisations do not use just one root key for signing certificates Dangerous, if that one key is compromised Does not scale to large organisations Difficulty in managing responsibility Certificate Hierarchies Start with CA root cert Create more levels in your organisation (for departments etc. ) Validating a cert possibly involves validating a path of trust Cross-certification is also possible This is the heart of “Planning of PKI”

Certificate Validation Essentially, this is just checking the digital signature But You may have to “walk the path” of all subordinate authorities until you reach the root Unless you explicitly trust a subordinate CA “In Xanadu We Trust” (installed root CA certificate) Check DS of OCG CA I: PB CA S: Rafal Check DS of Xanadu I: Xanadu Root S: PB CA I: Xanadu Root S: Xanadu Root

Recommendations Don’t be scared of PKI! Set up a test environment to enable hyou to “play” Minimise the scope of your first implementation Read up on CP & CPS Document the purpose and operating procedures of your PKI

Summary Cryptography is a rich and amazingly mature field We all rely on it, everyday, with our lives Know the basics and make good choices avoiding common pitfalls Plan your PKI early Avoid very new and unknown solutions

References Visit www. microsoft. com/security Read sci. crypt (incl. archives) Attend SEC 499 for “Encryption in Detail” on Friday at 14. 45 in Room 1 For more detail, read: Cryptography: An Introduction, N. Smart, Mc. Graw-Hill, ISBN 0 -07 -709987 -7 Practical Cryptography, N. Ferguson & B. Schneier, Wiley, ISBN 0 -471 -22357 -3 Contemporary Cryptography, R. Oppliger, Artech House, ISBN 1 -58053 -642 -5 (to be published May 2005, see http: //www. esecurity. ch/Books/cryptography. html) Applied Cryptography, B. Schneier, John Wiley & Sons, ISBN 0 -471 -11709 -9 Handbook of Applied Cryptography, A. J. Menezes, CRC Press, ISBN 0 -84938523 -7, www. cacr. math. uwaterloo. ca/hac (free PDF) PKI, A. Nash et al. , RSA Press, ISBN 0 -07 -213123 -3 Foundations of Cryptography, O. Goldereich, www. eccc. uni-trier. de/eccc-local/ECCC-Books/oded_book_readme. html Cryptography in C and C++, M. Welschenbach, Apress, ISBN 1 -893115 -95 -X (includes code samples CD)

Demonstrations Secure Email – sign and/or encrypt messages Secure browsing – SSL – auth and encryption Secure code – authenticode - sigcheck Secure wireless – PEAP & EAP-TLS Secure documents – Rights Management Secure networks – segmentation via IPsec Secure files – Encrypted File System(EFS)

Thanks to Rafal Lukawiecki for providing some of the content for this presentation deck – his contact details are as follows… rafal@projectbotticelli. co. uk Strategic Consultant, Project Botticelli Ltd Copyright 2004 © Project Botticelli Ltd & Microsoft Corp. E&OE. For informational purposes only. No warranties of any kind are made and you have to verify all information before relying on it. You can re-use this presentation as long as you read, agree, and follow the guidelines described in the “Comments” field in File/Properties.

Common Algorithms

DES, IDEA, RC 2, RC 5, Twofish Symmetric DES (Data Encryption Standard) is still the most popular Keys very short: 56 bits Brute-force attack took 3. 5 hours on a machine costing US$1 m in 1993. Today it is done real-time Triple DES (3 DES) more secure, but better options about Just say no, unless value of data is minimal IDEA (International Data Encryption Standard) Deceptively similar to DES, and “not” from NSA 128 bit keys RC 2 & RC 5 (by R. Rivest) RC 2 is older and RC 5 newer (1994) - similar to DES and IDEA Blowfish, Twofish B. Schneier’s replacement for DES, followed by Twofish, one of the NIST competition finalists

Rijndael (AES) Standard replacement for DES for US government, and, probably for all of us as a result… Winner of the AES (Advanced Encryption Standard) competition run by NIST (National Institute of Standards and Technology in US) in 1997 -2000 Comes from Europe (Belgium) by Joan Daemen and Vincent Rijmen. “X-files” stories less likely (unlike DES). Symmetric block-cipher (128, 192 or 256 bits) with variable keys (128, 192 or 256 bits, too) Fast and a lot of good properties, such as good immunity from timing and power (electric) analysis Construction, again, deceptively similar to DES (Sboxes, XORs etc. ) but really different

CAST and GOST CAST Canadians Carlisle Adams & Stafford Tavares 64 bit key and 64 bit of data Chose your S-boxes Seems resistant to differential & linear cryptanalysis and only way to break is brute force (but key is a bit short!) GOST Soviet Union’s “version” of DES but with a clearer design and many more repetitions of the process 256 bit key but really 610 bits of secret, so pretty much “tank quality” Backdoor? Who knows…

Careful with Streams! Do NOT use a block cipher in a loop Use a crypto-correct technique for treating streams of data, such as CBC (Cipher Block Chaining) For developers: . NET Framework implements it as ICrypto. Transform on a crypto stream with any supported algorithm

RC 4 Symmetric Fast, streaming encryption R. Rivest in 1994 Originally secret, but “published” on sci. crypt Related to “one-time pad”, theoretically most secure But! It relies on a really good random number generator And that is the problem Nowadays, we tend to use block ciphers in modes of operation that work for streams

RSA, DSA, El. Gamal, ECC Asymmetric Very slow and computationally expensive – need a computer Very secure Rivest, Shamir, Adleman – 1978 Popular and well researched Strength in today’s inefficiency to factorise into prime numbers Some worries about key generation process in some implementations DSA (Digital Signature Algorithm) – NSA/NIST thing Only for digital signing, not for encryption Variant of Schnorr and El. Gamal sig algorithm El. Gamal Relies on complexity of discrete logarithms ECC (Elliptic Curve Cryptography) Really hard maths and topology Improves RSA (and others)

Quantum Cryptography Method for generating and passing a secret key or a random stream Not for passing the actual data, but that’s irrelevant Polarisation of light (photons) can be detected only in a way that destroys the “direction” (basis) So if someone other than you observes it, you receive nothing useful and you know you were bugged Perfectly doable over up-to-120 km dedicated long fibre-optic link Seems pretty perfect, if a bit tedious and slow Practical implementations still use AES/DES etc. for actual encryption Magiq QPN: http: //www. magiqtech. com/press/qpn. pdf Don’t confuse it with quantum computing, which won’t be with us for at least another 50 years or so, or maybe longer…

MD 5, SHA Hash functions – not encryption at all! Goals: Not reversible: can’t obtain the message from its hash Hash much shorter than original Two messages won’t have the same hash MD 5 (R. Rivest) 512 bits hashed into 128 Mathematical model still unknown But it resisted major attacks SHA (Secure Hash Algorithm) US standard based on MD 5

Diffie-Hellman, “SSL”, Certs Methods for key generation and exchange DH is very clever since you always generate a new “keypair” for each asymmetric session STS, MTI, and certs make it even safer Certs (certificates) are the most common way to exchange public keys Foundation of Public Key Infrastructure (PKI) SSL uses a protocol to exchange keys safely See later

Cryptanalysis Brute force Good for guessing passwords, and some 40 -bit symmetric keys (in some cases needed only 27 attempts) Frequency analysis For very simple methods only (US mobiles) Linear cryptanalysis For stronger DES-like, needs 243 plain-cipher pairs Differential cryptanalysis Weaker DES-like, needs from 214 pairs Power and timing analysis Fluctuations in response times or power usage by CPU

Strong Systems It is always a mixture! Changes all the time… Symmetric: AES, min. 128 bits for RC 2 & RC 5, 3 DES, IDEA, carefully analysed RC 4, 256 bit better Asymmetric: RSA, El. Gamal, Diffie-Hellman (for keys) with minimum 1024 bits (go for the maximum, typically 4096, if you can afford it) Hash: Either MD 5 or SHA but with at least 128 bit results, 256 better

Weak Systems Anything with 40 -bits (including 128 and 56 bit versions with the remainder “fixed”) Most consider DES as fairly weak algorithm CLIPPER A 5 (GSM mobile phones outside US) Vigenère (US mobile phones) Dates from 1585! Unverified certs with no trust Weak certs (as in many “class 1” personal certs)