Freitag, November 10, 2006

DEV358 New Cryptography: Algorithms, APIs and Architecture


Rafal Lukawiecki
Abstract:
Are you still using DES, RSA, MD5 or SHA-1? Do you know how this might expose your company to a loss? Why is CAPI 1.0 being retired? Is the architecture of the new Open Cryptographic API for Windows (CNG) any better than CAPI 2? What is Suite-B? Do you realise that the next few years will see a dramatic replacement of those security fundamentals we used to silently rely on? These are some of the question we will answer in this information-packed and fast-paced level 300 session aimed Developers and Architects who are already familiar with basic cryptographic and security concepts. While we are not going to explain the inner workings of any of the covered algorithms, we will give you a good background to all the new ones, so that you can make better choices while designing security for your systems. Microsoft Windows Vista will be the first commercial operating system to include a full support for all of those innovations, closely followed by the “Longhorn” Server, so consider this as an opportunity to incorporate the awesome power of the recent developments in your software. For the curious, we may even tell you why we cannot tell you about Suite-A...


So, letzte Session an dieser TechEd. Leider… obwohl ich müde bin und den Kopf voller neuer Sachen habe ;-) Ist immer interessant, aber auch sehr anstrengend und ermüdend. Zum Schluss gönn ich mir nochmals (das 1. Mal in diesem Jahr) Rafal Lukawiecki. Rafal ist einer meiner lieblings Speaker. Ich habe ihn vor 3 Jahren das erste Mal gesehen und war begeistert. Er kann sehr komplexe Themen sehr bildlich und immer mit einer prise Humor rüberbringen. Ich habe durch ihn damals das 1. Mal das Konzept von Public und Private Key wirklich verstanden. Also bin ich nun gespannt was kommt. Wie ich Rafal kenne, wird er aber unsere Köpfe trotzt der letzten Session nicht in den "Idle" Modus versetzen.
Rafal beginnt mit einer Erklärung, wo dass heute in der Kryptographie sind und weshalb es einen neue braucht. Er erklärt, dass es sein Ziel ist, uns alle zu Kryptographie Fans zu machen ;-)
Er geht davon aus , dass alle Anwesenden wissen, was Symmetric, Public Key und Hibryd Kryptographie ist….

Heutige, vor Vista Empfehlungen:
At present (Nov 2006), consider using the following cryptographic mechanisms available in Windows XP and Server 2003 in preference to others:
• AES-128 (or AES-192, or AES-256)
• RSA 2048 (or longer)
• “SHA-2” (i.e. SHA-256, or SHA-512)
• DSA (or SHA-2/RSA signatures)


DES, IDEA, RC2, RC5, Twofish are not Recommended !!!


Rijndael (AES) Recommended :

Current US standard
• 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

CAST and GOST
Not used widely anymore – avoid

• 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…


Rely on Cryptosystems
Please:

• 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)
• Microsoft never implement just an algorithm – always a complete cryptosystem, e.g. RSA-OAEP etc.


Dangerous Implementations:
• Cryptographic applications from not-well-known sources
• I “just downloaded this library”
• Insist on using built-in systems where possible:
• Microsoft OS: CNG, CAPI, CAPICOM, MS CSP etc.
• Smartcards: certified CSPs
• Elsewhere: FIPS-140-2 compliant implementations
○ See csrc.nist.gov/cryptval

RC4
Generally Not Recommended
• 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 a problem
• Nowadays, we tend to use block ciphers in modes of operation that work for streams

RSA, DSA, ElGamal
• Asymmetric
• Slow and computationally expensive – need a computer
• Security increasingly being questioned
• 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)
• Mainly for digital signing, not for encryption, used in US
• Variant of Schnorr and ElGamal signature algorithm
• ElGamal
• Relies on complexity of discrete logarithms

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
• MD5 and MD4 broken
• SHA-0 broken (July 2004), SHA-1 probably too weak (partly broken, full break alleged by Chinese recently), use SHA-256 at least

Diffie-Hellman, “SSL”, Certs
• Methods for key exchange and transport
• DH (1976) always generates a new “key-pair” for each asymmetric session
• Certificates are the most common way to exchange public keys
• Foundation of Public Key Infrastructure (PKI)
• SSL uses a protocol to exchange keys safely, but also requires PKI


APIs of Today
• Microsoft CryptoAPI (CAPI) 2.0 is the interface to all CSPs
• Cryptographic Service Providers
○ Built-in or smartcard-based
• .NET Framework 1.1 and 2.0 (and 3.0) wraps most of the functionality of CAPI in classes:
• System.Security.Cryptography and its subclasses:
○ .Pkcs
○ .X509Certificates
○ .XML
• Or you can use the CAPICOM library

Cryptography of Tomorrow
Quantum Cryptography?
• Method for generating and passing a secret key or a random stream
• For keys, not data
• Polarisation of light (photons) can be detected only in a way that destroys the “direction” (basis)
• Works up-to-120km of a dedicated 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…

More Practical Solution

• US NSA and NIST recommendation is to implement “Suite-B” protocols
• This is very rarely done in today’s software
• Good news: Microsoft supports Suite-B in Windows Vista (and Longhorn Server)
• For all internal implementations Microsoft will not use weaker algorithms than Suite-B
○ But, of course, they will support your choice to do so if you wish

Vista Supports NSA Suite B
www.nsa.gov/ia/industry/crypto_suite_b.cfm

• Required cryptographic algorithms for all US non-classified and classified (SECRET and TOP-SECRET) needs
• Except a small area of special-security needs (e.g. nuclear security) – guided by Suite A (definition is classified)
• Announced by NSA at RSA conference in Feb 2005

Mathematical Designs

• Many cryptographic algorithms (e.g. DSA) rely on a class of mathematical designs related to the concept of discrete logarithms
• These can be implemented over the finite field of any abelian group
• Normally, this means using integers modulo a prime number
• Alternatively, elliptic curve groups could be used
• This leads to ECC


Elliptic Curve Cryptography
ECC
• More efficient design, using fewer bits of key for the same strength
• Breaking these designs seems even harder than traditional ones
• Leads to faster algorithms with fewer problems
• Primarily used to enhance algorithms of existing design, such as DSA


Suite-B Algorithms

• Encryption: AES
• Digital Signature: EC-DSA
• Key Exchange: EC-DH or EC-MQV
• Hashing: SHA-2

Suite-B Encryption

• AES
• FIPS 197 (with keys sizes of 128 and 256 bits)
• This is a specific implementation of Rijndael algorithm allowing use of 128 bit data blocks only
• Keys of 192 bits are not used (although FIPS specifies them)
• Please note that most 256 bit implementations are much slower than 128 bits
• In general, anything of 81 bits or more in this class of cryptography is considered “good enough” for typical commercial applications

Suite-B Digital Signatures

• Elliptic Curve Digital Signature Algorithm (EC-DSA)
• FIPS 186-2 (using the curves with 256 and 384-bit prime moduli)
○ Microsoft also supports 521-bit keys
• This is a classical DSA algorithm applied over the algebra of finite fields of elliptic curves
Suite-B Key Exchange
• Elliptic Curve Diffie-Hellman or Elliptic Curve MQV
• Draft NIST Special Publication 800-56 (using the curves with 256 and 384-bit prime moduli)
• Microsoft will also support 521-bit keys
• Remember DH?
• It is susceptible to man-in-the-middle attacks, so it requires authentication in most applications
• Usually done (not very efficiently) with digital signatures
• EC-MQV: Menezes, Qu, and Vanstone protocol
• Authenticated key exchange
• Design similar to DH
• Uses the discrete logarithm concept
• Also requires a pre-existing, verified and trusted long-term public/private keypair
○ Which is only used for trust establishment, not for actual encryption or signing
○ This gives it an important forward-secrecy property
• Suite-B uses the EC implementation of MQV

Suite-B Hashing

• Secure Hash Algorithm
• FIPS 180-2 (using SHA-256 and SHA-384)
• As MD5 and SHA-0 have been broken and SHA-1 has been allegedly broken we do not have much choice
• Almost no alternatives exist
• SHA-2 should suffice for a few years, but ultimately it must be replaced
• SHA-2 allows: 224, 256, 384, and 512 bit lengths

APIs for Suite-B Today?

• There are no widely used or supported libraries or APIs for Suite-B and most operating systems of today
• However…

Cryptographic Next Generation API
CNG

• CAPI 1.0 has been deprecated
• May be dropped altogether in future Windows releases
• CNG
• Open cryptographic API for Windows Vista/Longhorn
• Ability to plug in kernel or user mode implementations for:
○ Proprietary cryptographic algorithms
○ Replacements for standard cryptographic algorithms
○ Key Storage Providers (KSP)
• Enables cryptography configuration at enterprise and machine levels

• Main CNG Features

• Cryptography agnostic
• Kernel-mode for performance and security (better performance than CAPI 1.0)
• FIPS-140 Certification
• 140-2 and Common Criteria (CC) on selected platforms
• 140-1 everywhere
• CC compliance for long-term key storage and audit
• Suite-B of course, but also supports all existing algorithms available through CryptoAPI 1.0
• Key Isolation and Storage using TPMs
• Developer-friendly model for plug-ins

Three APIs within CNG:

• CNG Cryptographic Primitive Functions
○ The “main” API: all algorithms are here
• CNG Key Storage Functions
○ Allows interaction with the new Key Storage Providers concept
§ Supports existing devices (smartcards) and future types of tokens
○ Interface for all secure key creation, including the EC-DH and EC-MQV* methods
○ Interface for import and export of keys using PKCS #7 and #8
• CNG Cryptographic Configuration Functions
○ For registering and managing additional cryptographic functions
Read: http://msdn2.microsoft.com/en-us/library/aa375276.aspx

In addition to CNG:

• .NET Framework System.Security.Cryptography
○ Microsoft will extend the .NET Framework to cover CNG in the future
○ At present, it is a Windows native API
• TBS: TPM Base Services
○ For interaction with Trusted Platform Modules
• Certificate Enrolment API



Using CNG – Two Models

• Depending on your needs, you use CNG with:
• Algorithms and keys provided by a Key Storage provider (such as smartcards)
○ All function names begin with “N”, such as NCryptOpenStorageProvider
○ This is the CNG Key Storage Functions API
§ Ncrypt.h, Ncrypt.lib and Ncrypt.dll
• Algorithms and keys generated by the operating system’s software providers
○ All function names begin with “B”, such as BCryptOpenAlgorithmProvider
○ This is the CNG Cryptographic Primitive Functions API
§ Bcrypt.h, Bcrypt.lib and Bcrypt.dll
• I only explain “B” in next slides, but “N” is very similar

So, Who Encrypts?
Reason for the Two APIs

• “B-API” if
• You want Vista/Longhorn (or future OS) to do the encryption, you use the “B-API”
○ Implementation provided by a Key Storage Provider
○ Microsoft or other
• “N-API” if
• You have a smartcard, HSM (hardware security module), or a TPM
○ All computations performed by the device
○ Generally, OS has nothing to do with that

Summary:
• Today’s cryptography has just accelerated its evolution
• Windows Vista and Longhorn Servers will be at the front of innovation in this field
• You can benefit from the increased security by using BitLocker or the APIs such as CNG
• Developers life is easier with CNG than ever with CAPI
• It is an exciting time to be using cryptography!

Es würde jetzt sehr lange dauern, alles was er am "Rande" noch erzählt hat. Wie erwartet, eine typische Rafal Session. Sehr interessant, auch wenn ich nicht alles auf Anhieb verstanden habe. Aber das ist bei Ihm meistens so. Das gehörte muss sich zuerst setzten, sich einige Gedanken darüber machen und irgendwann wird ein Lichtlein aufgehen .. ;-) Die Folien habe ich mir gesichert, so dass ich sie mir immer und immer wieder reinziehen kann ….

Obwohl dies die letzte Session war, wartet noch mit "ausschalten". Ich habe diesen Beitrag zu einem grossen Teil noch im Flugzeug geschriebe. Will sagen, ich hab mindestens noch ein Fazit, ein paar Bilder usw.... stay tuned! (Aber zuerst geniesse ich jetzt das weekend, zumindest was davon übrgbleibt ;-) )

Keine Kommentare: