1 / 47

Cryptography and PKI for Passive Security

Cryptography and PKI for Passive Security. Rafal Lukawiecki Strategic Consultant, Project Botticelli Ltd. Objectives. Overview the basis of passive security mechanisms that primarily protect the data layer : cryptography

pilis
Download Presentation

Cryptography and PKI for Passive Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Cryptography and PKI for Passive Security Rafal Lukawiecki Strategic Consultant, Project Botticelli Ltd

  2. Objectives • Overview the basis of passive security mechanisms that primarily protect the data layer: cryptography • Discuss all currently used algorithms from an IT Professional’s perspective • Make some simple recommendations • Warn against typical misconceptions and weak algorithms

  3. Session Agenda • Foundational Concept • Common Algorithms • PKI and Signatures • Recommendations

  4. Foundational Concepts

  5. Defense in Depth Policies, Procedures, & Awareness Physical Security Data Application Host Internal Network Perimeter

  6. What is Really Secure? • Look for systems • From well-know parties • With published (not secret!) algorithms • That generate a lot of interest • That have been hacked for a few years • That have been analysed mathematically • Absolutely do not “improve” algorithms yourself • Unless this is your speciality

  7. Don’t Take Crypto For Granted • Classic failures: • DVD content encryption • GSM • WiFi • Good example of mis-use of crypto with WEP • Followed by a round of fixes, such as Mirosoft 802.1x • Finally followed by a more reasonable solution, WPA

  8. Symmetric Key Cryptography Plain-text input Plain-text output Cipher-text “The quick brown fox jumps over the lazy dog” “The quick brown fox jumps over the lazy dog” “AxCv;5bmEseTfid3)fGsmWe#4^,sdgfMwir3:dkJeTsY8R\s@!q3%” Encryption Decryption Same key(shared secret)

  9. 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

  10. 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

  11. private public Public Key Encryption Clear-text Input Clear-text Output Cipher-text “The quick brown fox jumps over the lazy dog” “The quick brown fox jumps over the lazy dog” “Py75c%bn&*)9|fDe^bDFaq#xzjFr@g5=&nmdFg$5knvMd’rkvegMs” Encryption Decryption Different keys Recipient’s private key Recipient’s public key

  12. 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

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

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

  15. Common Algorithms

  16. DES, IDEA, RC2, RC5, Twofish S/MIME, SSL, Kerberos • 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$1m in 1993. Today it is done real-time • Triple DES (3DES) 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 • RC2 & RC5 (by R. Rivest) • RC2 is older and RC5 newer (1994) - similar to DES and IDEA • Blowfish, Twofish • B. Schneier’s replacement for DES, followed by Twofish, one of the NIST competition finalists .NET Fx PGP .NET Fx S/MIME, SSL Java

  17. Rijndael (AES) .NET Fx • 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 (S-boxes, XORs etc.) but really different

  18. 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…

  19. Use Cryptosystems • Indeed: never use just an algorithm, but an entire cryptosystem • For example: • If you use DES etc. in a simple “loop” to encrypt a stream of data you literally lose all security • Instead: use a technique designed for adapting an algorithm to a streams of data, such as CBC (Cipher Block Chaining) • In turn, this means you have to select and transmit an Initialization Vector (IV) – how? • Use a well-known cryptosystem for it • Microsoft never implement just an algorithm – always a complete cryptosystem, e.g. RSA-OAEP etc.

  20. Dangerous Implementations • Cryptographic applications from not-well-known sources • “Just downloaded libraries” used by your in-house developers • Insist on using built-in systems where possible: • Microsoft OS: CAPI, CAPICOM, MS CSP etc. • Smartcards: built-in well-known CSPs • Elsewhere: FIPS-compliant implementations

  21. RC4 • 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 PPTP

  22. RSA, DSA, ElGamal, 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 ElGamal sig algorithm • ElGamal • Relies on complexity of discrete logarithms • ECC (Elliptic Curve Cryptography) • Really hard maths and topology • Improves RSA (and others) SSL, PGP .NET Fx .NET Fx

  23. 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-120km 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…

  24. MD5, SHA • Hash functions – part of the digital signature • Goals: • Not reversible: can’t obtain the message from its hash • Hash much shorter than original message • Two messages won’t have the same hash • MD5 (R. Rivest) • 512 bits hashed into 128 • Mathematical model still unknown • Recently (July 2004) broken, do not use on its own • SHA (Secure Hash Algorithm) • US standard based on MD5 • SHA-0 broken (July 2004), SHA-1 probably too weak (partly broken), use SHA-256 at least Everywhere

  25. Diffie-Hellman, “SSL”, Certs PGP • Methods for key generation and exchange • DH is clever since you always generate a new “key-pair” 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 Everyone

  26. 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 • Useful for breaking a stolen smartcard

  27. Breaking It on $10 Million From a report by Robert Silverman, RSA Laboratories, 2000

  28. PKI and Signatures

  29. 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 • Bill does not have the private key to read them… • Scott reads Bill’s messages 

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

  31. How to Verify a Public Key? • Two approaches: • 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 • 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…

  32. 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

  33. private Creating a Digital Signature Message or File Digital Signature 256 bits Message Digest This is a really long message about Bill’s… Jrf843kjfgf*£$&Hdif*7oUsd*&@:<CHDFHSD(** Py75c%bn&*)9|fDe^bDFaq#xzjFr@g5=&nmdFg$5knvMd’rkvegMs…” Hash Function (SHA, MD5) AsymmetricEncryption Calculate a short message digest from even a long input using a one-way message digest function (hash) Signatory’s private key

  34. Digital Signature Jrf843kjfgf*£$&Hdif*7oUsd*&@:<CHDFHSD(** Asymmetricdecryption (e.g. RSA) Py75c%bn&*)9|fDe^bDFaq#xzjFr@g5=&nmdFg$5knvMd’rkvegMs” ? == ? Are They Same? Signatory’s publickey Py75c%bn&*)9|fDe^bDFaq#xzjFr@g5=&nmdFg$5knvMd’rkvegMs” Same hash function(e.g. MD5, SHA…) Everyone has access to trusted public key of the signatory This is a really long message about Bill’s… Original Message Verifying a Digital Signature

  35. Message Authentication Codes • “MACs” – Typically, combination of a hash function and a symmetric encryption • Integrity, authenticity but not non-repudiation • Must share the key! • HMAC • Digest + shared-secret encryption for up to 160 bit results • MACTripleDES • Encryption using 8, 16 or 24 bytes of TripleDES key on top of a hash • 64 bit result (generally insufficent) • Frequently used in transactions and databases

  36. 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 a CA)

  37. X.509 Certificate OU=Project Botticelli… The Key or Info About It

  38. Authentication with Certificates • 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? • Melinda challenges Bill to encrypt for her a phrase etc. she just made up (“I really need more shoes”) • Bill has, of course, the private key that matches the certificate, so he responds (“*&$^%£$&£fhsdf*&EHFDhd62^&£”) • 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

  39. 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

  40. 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

  41. 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 • Typically 3 tiers: 2 offline and 1 online • Validating a cert possibly involves validating a path of trust • Cross-certification (“mesh”, “web”) is possible

  42. Recommendations

  43. Strong Systems • It is always a mixture! Changes all the time… • Symmetric: • AES, min. 128 bits for RC2 & RC5, 3DES, IDEA, carefully analysed RC4, 256 bit better • Asymmetric: • RSA, ElGamal, Diffie-Hellman (for keys) with minimum 1024 bits (go for the maximum, typically 4096, if you can afford it) • Hash: • SHA with at least 256 bits

  44. Weak Systems • Anything with 40-bits (including 128 and 56 bit versions with the remainder “fixed”) • Most consider DES as fairly weak algorithm • CLIPPER • A5 (GSM mobile phones outside US) • Vigenère (US mobile phones) • Dates from 1585! • Hashes (and sigs) based on MD5 or SHA-0 (perhaps SHA-1 too) or 64 bit hashes • Unverified certs with no trust • Weak certs (as in many “class 1” personal certs)

  45. Conclusions

  46. Summary • Cryptography is a rich and 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

  47. References • Visit www.microsoft.com/security • Read sci.crypt (incl. archives) • For more detail, read: • Cryptography: An Introduction, N. Smart, McGraw-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-8493-8523-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)

More Related