introduction to pki technology
DESCRIPTION
Formation HES Yverdon 2003TRANSCRIPT
e-Xpert Solutions SA | 29, route de Pré-Marais | CH 1233 Bernex-Genève | Tél +41 22 727 05 55 | Fax +41 22 727 05 50
[email protected] | www.e-xpertsolutions.com
Introduction to PKI Technology
Sylvain MaretFévrier 2002Version 2.01
Solutions à la clef
Course Map Day One
Introduction Key Terms
Cryptosystems Services, Mechanisms, Algorithms
Cryptography in History Cryptanalysis
Solutions à la clef
Course Map Day One
Secret-Key Cryptography AES
Public-Key Cryptography RSA Diffie-Hellman
Message Digests Random Numbers Key Length
Solutions à la clef
Course Map Day One
Message Authentication Code (MAC, HMAC) Digital Signature
RSA, DSS / DSA, ElGamal Hybrid Cryptosystems
RSA Key Wrapping Diffie-Hellman
PKCS Standard Smart Card End of day one
Solutions à la clef
Course Map Day Two
Questions to day one ? Revision quiz ! PKI introduction
Digital certificates X.509 certificates (Demo) Certificate Revocation (Demo) Certification Authorities RA, LRA Data Repositories (LDAP)
Solutions à la clef
Course Map Day two
S/MIME: How it works ? SSL: How it works ? IPSEC: How it works ? Open discussion Encryption references sites
Solutions à la clef
Course Objectives
Understand cryptographic fundamentals and how cryptographic technology is applied in a Public Key Infrastructure
Know the elements of Public Key Infrastructure and how they interact with each other
Understand and be able to describe some of the practical applications of PKI
Understand why PKI is an attractive technology to enable e-commerce and enhance security
Solutions à la clef
PKI, WHY?
The rise of public data networks. Internet is a new platform for business
relationships: E-business Business rules need to be “translated” into this
new “language”. Hope behind PKI: to preserve classical business
rules in this new virtual world.
Solutions à la clef
Drawbacks for E- business
Let’s say you have an electronic contract which you need to distribute to another party over the Internet…
With existing Internet tools like www and e-mail you lose a lot compared to paper
No assurance that the contract has been signed No guarantee that the contract is authentic No assurance of the contract’s source
Basically, it is worth than the paper where everything is printed on!
Solutions à la clef
About needs...
You need to know who you are dealing with (Authentication)
You need to keep private things private (Confidentiality)
You need to make sure that people do not cheat (Non-Repudiation)
You need to be sure that information has not been altered (Integrity)
Solutions à la clef
If PKI is the answer then…
What is the question?
On the Internet no one knows you're a dog!
Solutions à la clef
Key Terms
A message will be defined as plaintext or cleartext
The process of disguising a message to hide its substance is encryption
The encrypted message is referred to as ciphertext
Decryption is the process turning ciphertext back into plaintext
Solutions à la clef
Key Terms
Cryptography is the science allowing messages to be kept secure
Cryptoanalysis is the art and science of breaking ciphertext
Cryptology is the mathematics field Cryptologist are theoretical mathematicians
Solutions à la clef
Cryptosystems
A cryptosystem is a collection of cryptographic algorithms, cryptographic keys, and all possible plaintexts and their corresponding ciphertexts.
Solutions à la clef
Security Services
Authentication: Provides the assurance of someone’s identity
Confidentiality: Protects against disclosure to unauthorized identities
Non-Repudiation: Protects against communications originator to later deny it
Integrity: Protects from unauthorized data alteration
Solutions à la clef
Security Mechanisms
Three basic building blocks are used: Encryption is used to provide confidentiality and
integrity protection Digital Signatures are used to provide authentication,
integrity protection and non-repudiation Checksums / hash algorithms are used to provide
integrity protection and can provide authentication
Solutions à la clef
Cryptography Algorithms
All Cryptosystems are based on only three algorithms:
1 - Secret-Key algorithms 2 - Public-Key algorithms 3 - Message-Digest algorithms
Solutions à la clef
Services, Mechanisms, Algorithms
A typical security protocol provides one or more services
Services
Mechanisms
Algorithms
Services are built from MechanismsMechanisms are implemented using Algorithms
SSL, IPSEC, TLS, SSH, etc...SSL, IPSEC, TLS, SSH, etc...
Signatures
Signatures
Encryption
Encryption HashingHashing
DSADSA RSARSA RSARSA DESDES SHASHA MD5MD5
Solutions à la clef
Security Protocol Layers
Application
Presentation
Session
Transport
DataLink
Physical
Application
Presentation
Session
Transport
Network
DataLink
Physical
Network
S/MIME, PGP
SSL, TLS, SSH
IPSEC
Hardware link encryption
The further down you go, the more transparent it isThe further up you go, the easier it is to deploy
Solutions à la clef
Cryptography in History
2000 B.C. Hieroglyphics Cryptography as an Art
Ancient Chinese First to transform messages in Ideographs for privacy
India First “Networks spies” using phonetics encryption
(Javanese or reverse speaking) Mesopotamia
Numbers associate to letters (cuneiform table)
Solutions à la clef
Cryptography in History
ATBASH cipher: In the Bible ABCDEFGH… (clear) ZYXWVU…(encrypted)
Skytale Cipher (Greek) key: stick papyrus enrolled
Polybius square (Greek)
Solutions à la clef
Cryptography in History
Runiques Stones by Vikings (Arts)
Solutions à la clef
Cryptography in History
World War II: Electromechanical cryptography Rotor based machine transforming plaintext into
ciphertext, using electrical signals as encryption key Example: Enigma machine used by Germans Ciphers were not new, but their processing was…
1970-today: New ciphers: based on numbers properties issued from
Mathematical theories RSA: Prime numbers factorization Diffie-Hellman: discrete logarithm ECDSA: Elliptic curve cryptography
Solutions à la clef
Cryptanalysis
Two categories of security levels Computationally secure:
Question of time and money (Brute force attack) (Most of the cryptosystems: DES, 3DES, IDEA, RSA, DH
etc.) Unconditionally secure:
Can “never” be broken independently of the resources One-time pads
Solutions à la clef
Several Cryptanalytic Attacks
Ciphertext only Brute force attack and dictionary attacks on keys
Chosen ciphertext Start from a known ciphertext and try to appear as
someone else to get information from others behavior Known Plain ciphertext
Derive the key from knowledge of both plain and ciphertext
e-Xpert Solutions SA | 29, route de Pré-Marais | CH 1233 Bernex-Genève | Tél +41 22 727 05 55 | Fax +41 22 727 05 50
[email protected] | www.e-xpertsolutions.com
Secret-Key Cryptography
Solutions à la clef
Secret-Key Cryptography
Use a secret key to encrypt a message into a ciphertext
Use the same key to decrypt the ciphertext into the original message
Secret-key cryptography is referred also as symmetric cryptography or conventional cryptography
The secret key is also known as session key or bulk encryption key
Solutions à la clef
Secret-Key Cryptography
Let us imagine Alice and Bob who use Secret-Key to protect their messages
PlaintextPlaintextCiphertextCiphertext
Secret-KeySecret-Key
Solutions à la clef
Secret-Key Cryptography
How to share the Secret-Key ? Alice and Bob can use the phone, fax, a meeting point,
etc. But!?:
Could someone steal the key? How to proceed without partner knowledge?
Solutions à la clef
Secret-Key Cryptography
The Advantages Implementation is efficient to encrypt large volume of
data (100 to 1’000 faster than Public-Key Cryptography)
Simple to implement in either software or hardware Most of the algorithms are well know and secure Seem to be safe to brute force attack Widely used
Solutions à la clef
Secret-Key Cryptography
The Disadvantages Hard to share Secret-Keys Large number of keys No non-repudiation (Signature) Subject to interception (Secret-Key)
Solutions à la clef
Secret-Key Cryptography
Number of needed keys Suppose Alice, Bob and Chris want to use Secret-Key
Cryptography! They need only 3 keys
Solutions à la clef
Secret-Key Cryptography
Increase of keys number Suppose they want to add Dawn and Eric
Now they need ten keys
Solutions à la clef
Secret-Key Cryptography
If n persons want to communicates we have this formula:
Key’s number = ((n)*(n-1)) / 2 As example: A company of 60’000 people =
1’799’970’000 keys!
Solutions à la clef
Secret-Key Cryptography
Block cipher: Encrypts data in predefined block size
Most well-known ciphers are block ciphers Stream cipher: Encrypts data stream, one-bit at
the time Only few algorithms use it
Solutions à la clef
Secret-Key Cryptography
Common Secret-Key Ciphers DES Triple DES (3DES) RC2 IDEA Blowfish CAST-128 Skipjack RC4 (Stream cipher) etc.
Solutions à la clef
Secret-Key Cryptography
DES Data Encryption Standard (1973) by IBM World Standard for 20 years DES was broken in 22 hours (DES challenge III, January
18th, 1999) Key size = 56 bits Block cipher
Recommendation: should be replaced by 3DES for high confidentiality requirements !
Solutions à la clef
Secret-Key Cryptography
Triple DES (3DES) Block cipher Encrypt + decrypt + encrypt with 2 (112 bits) or 3
(168 bits) DES keys DES’s replacement for Banking (1998)
Recommendation: Use it for high confidentiality!
Solutions à la clef
Secret-Key Cryptography
RC2 Designed by Ron Rivest from RSA Block cipher Key size = up to 2048 Encryption speed: independent from the key size Trade secret from RSA, posted on the net in 1996 Designed as a DES’ replacement Faster than DES
Recommendation: like DES but faster!
Solutions à la clef
Secret-Key Cryptography
CAST-128 Designed by C.Adams and S. Tavares (1993) Block cipher Key size = 128 bits Used in PGP 5.x
Recommendation: unknown
Solutions à la clef
Secret-Key Cryptography
IDEA International Data Encryption Algorithm Designed by X.Lai and J. Massey (ETH Zurich) in 1990 Block cipher Key size = 128 bits More efficient than DES for software implementation Used in PGP
Recommendation: Better than DES
Solutions à la clef
Secret-Key Cryptography
Blowfish Designed by B. Schneier in 1993 Optimized for high-speed execution on 32-bit
processors Block cipher Key size = up to 448 bits key
Recommendation: Use for fast performances and with a maximum key size
Solutions à la clef
Secret-Key Cryptography
Skipjack Designed by NSA (National Security Agency) Block cipher Key size = 80 bits
Recommendation: Inadequate for long term security (key size too short)
Solutions à la clef
Secret-Key Cryptography
GOST Acronym for “GOsudarstvennyi STandard” Russian answer to DES Key size = 256 bits
Recommendation: Incompletely specified to give an answer...
Solutions à la clef
Secret-Key Cryptography
RC4 Designed by Ron Rivest from RSA Stream cipher Key size = up to 2048 bits Optimized for fast software implementation Trade secret from RSA, posted on the net in 1994 Very fast Used in SSL, Lotus Note, Windows password
encryption, Oracle etc. Recommendation: Highly recommended for long
keys (>40 bits)
Solutions à la clef
Secret-Key Cryptography
Many, many others There is no good reason not to use one of above
proven algorithms!
Solutions à la clef
Secret-Key Relative Performance
RC4 Blowfish, CAST-128 Skipjack DES, IDEA, RC2 3DES, GOST
FAST
SLOW
Solutions à la clef
AES
National Institute of Standard and Technology expressed a formal call for algorithm on 09.1997
The aim is to define the “next century’s” symmetric encryption standard or Advanced Encryption Standard
AES1 conf. (08.98): 15 potential candidates AES2 conf. (03.99): 5 retained candidates Final choice expected for summer 2001
Solutions à la clef
AES candidates
MARS (IBM) RC6 (RSA Laboratories) Rijndael (J. Daemen, V. Rijmen) Serpent (R. Anderson, E. Biham, L. Knudsen) Twofish (B. Schneier - Counterpane)
Solutions à la clef
AES requirements
Block cipher of minimum 128 bits Must implement symmetric keys of 128, 192,
256 bits Must be efficient on software and hardware
basis (high speed encryption)
e-Xpert Solutions SA | 29, route de Pré-Marais | CH 1233 Bernex-Genève | Tél +41 22 727 05 55 | Fax +41 22 727 05 50
[email protected] | www.e-xpertsolutions.com
Public Key Cryptography
Solutions à la clef
Public-Key Cryptography
Use two distinct keys, one public and one private
The private is kept secret The public can be freely shared Referred as asymmetric cryptography A public-key and its corresponding key are
mathematically related A public-key and its associated private-key are
called a key-pair
Solutions à la clef
Public-Key Cryptography
A message encrypted with a public-key can be only decrypted by the private-key
A message encrypted with a private-key can be only decrypted by the public-key (Signature)
Solutions à la clef
Public-Key Cryptography
Suppose Alice wants to send a message to Bob using Public-Key Cryptography
PlaintextPlaintext PlaintextPlaintextCiphertextCiphertext
Bob’s public keyBob’s public key Bob’s private keyBob’s private key
Solutions à la clef
Public-Key Cryptography
How to obtain the public-key ? Any publishing way can be used to get the public-key
(Directory servers, Phone, Web server, Newspapers etc.)
No more confidentiality issues in key distribution
Solutions à la clef
Public-Key Cryptography
Advantages No secret sharing Fewer keys No prior relationship needed Easier to administrate Offers useful mechanisms like digital signature
(offering non repudiation)
Solutions à la clef
Public-Key Cryptography
Disadvantages Not efficient (slow) to encrypt large volume of data Keys need to be much longer than with secret-key
encryption Impossible to encrypt a plaintext with size > key
Solutions à la clef
Types of public-key algorithm
A public-key algorithm is reversible if encryption and decryption can be processed with either a private or a public-key
A public-key algorithm is irreversible if a private-key is mandatory for encryption
Key exchange algorithm: neither used for encryption nor decryption (Diffie-Hellman)
Solutions à la clef
RSA
Inventors: Rivest, Shamir, Adleman in 1977 Most popular Provide confidentiality, digital signature and key
exchange Key length up to 4096 Plaintext length < Key length Ciphertext size = Key size
Solutions à la clef
RSA
RSA is protected by a patent. Patent expires on 20th September 2000
Relies on irreversible mathematics functions (Prime numbers)
Solutions à la clef
Diffie-Hellman
Published in 1976 by W. Diffie and M. Hellman Oldest known public-key cryptosystem Key agreement algorithm
Enables secret-key exchange without prior knowledge Agrees on shared secret used in conjunction with a
secret-key Cryptosystem (DES, 3DES, IDEA, etc.)
Solutions à la clef
Diffie-Hellman: How it works ?
Share Secret KeyShare Secret Key Share Secret KeyShare Secret Key
Alice’sprivate key
Bob’sprivate key
Alice’spublic key
Bob’spublic key
=
Solutions à la clef
DSA
Compliant to Digital Signature Standard (DSS) Published in 1994 Irreversible algorithm (encryption with private
key only) Used in Digital signature only Performance tuned for smart cards
Solutions à la clef
Comparative Public-Key table
Algorithm Type
DSA Digital Signature
El-Gamal Digital Signature
RSA ConfidentialityDigital SignatureKey exchange
Diffie-Hellman Key exchange
e-Xpert Solutions SA | 29, route de Pré-Marais | CH 1233 Bernex-Genève | Tél +41 22 727 05 55 | Fax +41 22 727 05 50
[email protected] | www.e-xpertsolutions.com
Message-Digest Algorithms
Solutions à la clef
Message-Digest Algorithms
Take a variable-length message and produce a fixed-length digest as output
The fixed-length output is called the message digest, a digest or a hash
A message-digest algorithm is also called a one-way hash algorithm or a hash algorithm
Solutions à la clef
Message-Digest Algorithms
Hash Function
Input
Message
Input
Message
Fixed-length DigestFixed-length Digest
Solutions à la clef
Message-Digest Algorithms
Message-Digest Algorithms properties required to be cryptographically secure
It must not be feasible to determine the input message based on its digest
It must not be possible to find an arbitrary message that has a particular, desired digest
It should be impossible to find two messages that have the same digest (collision)
It should be very sensitive to input message changes
Solutions à la clef
Message-Digest Algorithms
Some Common Message-Digest Algorithms MD2: 128-bit-output, deprecated, by Ronald Rivest MD4: 128-bit-output, broken, by Ronald Rivest MD5: 128-bit-output, weaknesses, by Ronald Rivest SHA-1: 160-bit-output, NSA-Designed RIPEMD-160: 160-bit-output Haval: 128 to 256 bit-output (3 to 5 Passes) CRC-32: 32-bit-output
Recommendation: Use SHA-1
Solutions à la clef
Message-Digest Algorithms
Message-Digest at work Creation of digital signatures Creation of MAC, HMAC Creation of secret-key with a passphrase File checksum (FTP server, Patches, etc.) FIA (File Integrity Assessment like Tripwire)
Solutions à la clef
Random Numbers
Random numbers are usually required to generate cryptographic keys or challenge.
Two main categories (PRNG) Pseudo Random Number Generator uses a
deterministic algorithm to generate a pseudo random number based on a seed (mouse, keyboard, etc..)
A random number generator generates truly unpredictable numbers. Based generally on special hardware (white noise, radioactive-decay, etc…)
e-Xpert Solutions SA | 29, route de Pré-Marais | CH 1233 Bernex-Genève | Tél +41 22 727 05 55 | Fax +41 22 727 05 50
[email protected] | www.e-xpertsolutions.com
Random Numbers
Solutions à la clef
Random Numbers
A very secure cryptosystem can be broken if it relies on random numbers that can be guessed
Netscape browser using SSL broken! Some PRNG
Yarrow from B. Schneier CryptPack etc.
Solutions à la clef
Keys Length
To break a secret-key cryptosystem with “no weakness”, an attacker must try each possible key. This is called a brute force attack
To break a public-key cryptosystem an attacker should use “smarter” brute force attack based on mathematics
Key space dimension = 2n (n:keylength)
e-Xpert Solutions SA | 29, route de Pré-Marais | CH 1233 Bernex-Genève | Tél +41 22 727 05 55 | Fax +41 22 727 05 50
[email protected] | www.e-xpertsolutions.com
Keys Length
Solutions à la clef
What is the right key size ?
The goals of cryptography are to make the value of encrypted information less than the money spent to decrypt it !
the value of information usually decreases over time
Solutions à la clef
RSA’s Challenge on DES (III)
Method: splitting the Key space for distributed Brute Force Attack (space dimension = 2n , where n is the key-length)
Starting date: 18.01.99. Ending: 22h15 min. later…
Brute Force Attack frequency: 245 Billions keys/sec.
Platforms: Cray/Sun/SGI/Pentium etc..
Solutions à la clef
RSA’s Challenge on RSA-155
Key-length: 512 bits = 155 digits Method: Prime number factorization Starting Date: August 99. Ending: 5 months
later Time: 35.7 CPU years Platforms: SGI/Sun/Pentium etc.
292 computers
Solutions à la clef
Keys’ time of life
Most of the time, session keys are changing (IPSec, etc.)
to enforce security Can be triggered by time or by encrypted data
quantity
Solutions à la clef
Public-Key vs Secret-key
Secret-key (bits) Public-Key (bits)
40 274
56 384
64 512
80 768
96 1024
112 1792
120 2048
128 2304
e-Xpert Solutions SA | 29, route de Pré-Marais | CH 1233 Bernex-Genève | Tél +41 22 727 05 55 | Fax +41 22 727 05 50
[email protected] | www.e-xpertsolutions.com
Message Authentication Code
Solutions à la clef
Message Authentication Code
MAC is a fixed-length data item that is send together with a message to prove integrity and origin
Provide authentication and integrity without confidentiality
Also referred as message integrity code (MIC) Most common form is HMAC ( Hashed Mac) Example: HMAC-MD5
Solutions à la clef
Message Authentication Code
+Secret-Key
Hash Function
Input
Message
Input
Message
HMACHMAC
e-Xpert Solutions SA | 29, route de Pré-Marais | CH 1233 Bernex-Genève | Tél +41 22 727 05 55 | Fax +41 22 727 05 50
[email protected] | www.e-xpertsolutions.com
Digital Signature
Solutions à la clef
Digital Signature
Digital signature is a data item that guarantees the origin and integrity of a message
The signer of the message uses a signing key The recipient uses a verification key to verify
the origin and integrity Signing key = private-key Verification key = public-key
Solutions à la clef
Digital Signature
By using his own private key, the signer can not repudiate the fact he has signed the message
This mechanism provide non-repudiation Think about the difference with MAC …
Solutions à la clef
Digital Signature: Basics
PlaintextPlaintext PlaintextPlaintextCiphertext
(Signature)
Ciphertext
(Signature)
Alice’s private keyAlice’s private key Alice’s public keyAlice’s public key
Simple signature using PRIVATE-key
Solutions à la clef
Digital Signature: How it works?
SignatureSignature
PlaintextPlaintext
Alice’s private key
SignatureSignature
Alice’s Public key
MD1 = MD2 ???MD1 = MD2 ???
PlaintextPlaintext
DigestDigest
Solutions à la clef
Digital Signature
Why signing a message involves Hashing ? Signature (data item) is too big Performance (public-key is very slow) Possible attack (known plaintext attack)
Solutions à la clef
Common Signature Algorithms
RSA Well known Export limitation
DSA Similar to RSA (algebraic properties of numbers) Non-reversible algorithm, suitable for digital signature
only ElGamal
Another cipher for digital signature only
e-Xpert Solutions SA | 29, route de Pré-Marais | CH 1233 Bernex-Genève | Tél +41 22 727 05 55 | Fax +41 22 727 05 50
[email protected] | www.e-xpertsolutions.com
Hybrid Cryptosystems
Solutions à la clef
Hybrid Cryptosystems
A Hybrid Cryptosystem combines the best features of both Secret-Key and Public-Key cryptography
Used to exchange session key to initiate a symmetric encryption
Example: PGP, SSL, IPSEC using Diffie-Hellman or RSA
Solutions à la clef
Example: Diffie-Hellman and Secret-Key cryptosystem
Share Secret KeyShare Secret Key Share Secret KeyShare Secret Key=
PlaintextPlaintext PlaintextPlaintextCiphertextCiphertext
Asymmetric
Symmetric
Solutions à la clef
RSA Key wrapping encryption
Suppose Alice wants to send an encrypted text to Bob across the Internet , using RSA key wrapping
Solutions à la clef
RSA Key wrapping encryption
How it works ? Alice creates a session key, which is a one-time-only
secret-key Alice encrypts the data with the session key Alice encrypts the session key with Bob’s public-key Alice sends the ciphertext + the encrypted session key
to Bob
Solutions à la clef
RSA Key wrapping encryption
Solutions à la clef
RSA Key wrapping decryption
How it works ? Bob receives the message from Alice Bob uses his private-key to recover the temporary
session key Bob uses the session key to decrypt the ciphertext
Solutions à la clef
RSA Key wrapping decryption
Solutions à la clef
RSA Key wrapping question ?
How sure can Alice be about Bob’s presumed public-key ?
Solutions à la clef
Man in the Middle Attack!
e-Xpert Solutions SA | 29, route de Pré-Marais | CH 1233 Bernex-Genève | Tél +41 22 727 05 55 | Fax +41 22 727 05 50
[email protected] | www.e-xpertsolutions.com
SSH: How it works ?
Solutions à la clef
SSH
SSH = Secure Shell Originally developed in 1995 as a secure
replacement for rsh, rlogin,rcp, ftp, telnet Originally implemented in Finland Available worldwide About 3’000’000 users around the world
Solutions à la clef
SSH
Also allows port forwarding (tunneling over SSH) X11 connection forwarding SSH v2 submitted to IETF Can be run and used in a short space of time Many SSH clients available
Secure CRT F-Secure Java Client etc.
Solutions à la clef
SSH: Why ?
Attacker with snifferNetwork
Original TCP Packet
Login: rome
Password: abc123
Unix HostUnix Host
Telnet to Unix HostTelnet to Unix Host
Solutions à la clef
SSH-1 Protocol (Hybrid Crypto)
TCP
Auth request
SSH
Client Server
DATA
Client performs TCP handshake with the server at port 22 for SSH standard portClient performs TCP handshake with the server at port 22 for SSH standard port
Start authentication process. Client send authentication requestStart authentication process. Client send authentication request
Server decrypt the session key with the two private keys. Begin bulk encrypted data exchange. Client encrypts
Server decrypt the session key with the two private keys. Begin bulk encrypted data exchange. Client encrypts
Server decrypts request, encrypts and sends responseServer decrypts request, encrypts and sends response
S
Symmetric Encrypteddata
SSHHandshakePublic Key
S
22
Session
The server responds with two keys. Host key 1024 bit RSA and a Server key 768 bit RSA (Generated hourly)
The server responds with two keys. Host key 1024 bit RSA and a Server key 768 bit RSA (Generated hourly)
Client verify host key and generate a secret key that is used for bulk encryption then encrypt this secret key twice with Host and Server public keys and send it to the server SSH
Client verify host key and generate a secret key that is used for bulk encryption then encrypt this secret key twice with Host and Server public keys and send it to the server SSH
Solutions à la clef
SSH Ciphers
SSH v1 RSA DES, 3DES, Blowfish, IDEA
SSH v2 Diffie-Hellman for key exchange algorithm DSA, RSA 3DES, Blowfish, IDEA, Twofish, Arcfour, Cast-128
Solutions à la clef
SSH Authentication
Multiple Authentication mechanisms Static password (protected by SSH encryption) RSA or DSA authentication (client decrypts challenge
from server) Plug-in authentication (Securid, Radius, ldap, PAM *) “.rhosts or /etc/hosts.equiv” (Based on IP address)
Solutions à la clef
SSH Authentication (RSA/DSA)
Client decrypts “challenge” from server Provides “strong” authentication (client uses his
private-key plus a PIN code)
Server sends encrypted challenge with client’s public key
Client decrypts challenge and sends it to the server
The challenge is chosen randomly
Solutions à la clef
SSH Tunneling mode
SSH
Server
SSH
Server
HTTP 127.0.0.1 1999HTTP 127.0.0.1 1999
Encrypted SSH tunnel Clear text
Web serverWeb server
DMZ
Corporate Net
SSH
Client
SSH
Client
e-Xpert Solutions SA | 29, route de Pré-Marais | CH 1233 Bernex-Genève | Tél +41 22 727 05 55 | Fax +41 22 727 05 50
[email protected] | www.e-xpertsolutions.com
PKCS
Solutions à la clef
PKCS
Public Key Cryptographic Standard (PKCS) Standardization of public-key algorithmic, in order to
maintain interoperability Developed by RSA Laboratories, a consortium of
information technology vendors and academic institutions.
Apple Microsoft Compaq Lotus Sun MIT etc.
Solutions à la clef
PKCS list
#1: Encrypting and signing using RSA public key cryptosystem #3: Key agreement with Diffie-Hellman key exchange #5: Encrypting with a secret key derived from a password #7: Syntax for message with digital signature #8: Format for private key information #9: Attribute type for use in other PKCS standard #10: Syntax for certification request #11: Define a cryptoki programming interface (API for smart
cards) #12: Portable format for storing and transporting private keys #13: Encrypting and signing data using elliptic curves
cryptography #14: Standard for pseudo number generation #15: Standard to store credentials on tokens
e-Xpert Solutions SA | 29, route de Pré-Marais | CH 1233 Bernex-Genève | Tél +41 22 727 05 55 | Fax +41 22 727 05 50
[email protected] | www.e-xpertsolutions.com
Smart Card
Solutions à la clef
Smart Card
Smart Cards consist of a chip (processor or/and memory), a contact plate and a piece of plastic (ISO 7810 - 54x85x0.8 mm)
Smart Cards are used for multi-applications GSM, Banking, Medical, E-Commerce, Pay TV, etc.
Solutions à la clef
Smart Card and PKI
Storing the private-key and/or X.509 certificate on the Smart Card
Provide Strong Authentication Something you have, Something you know Access protected by a PIN (like credit card)
Types of Smart Card Memory Cards PKI smart cards using Crypto-processor (RSA, etc.)
Some Smart Card are “brute force” protected
Solutions à la clef
Smart Card Standard (interface)
PKCS #11 also call Cryptoki Interface for the communication to Smart Card Netscape, RSA
PC/SC and their Crypto API http://www.pcscworkgroup.com/ Bull, Gemplus, HP, Intel, Microsoft, Schlumberger
Siemens, SUN, Toshiba
Solutions à la clef
Smart Card Reader
Keyboard USB Serial PCMCIA Diskette reader SCSI
Solutions à la clef
Today’s Smart Card Drawbacks
Hardware... Multi-Services rarely used
Users leave Smart Card on the reader
e-Xpert Solutions SA | 29, route de Pré-Marais | CH 1233 Bernex-Genève | Tél +41 22 727 05 55 | Fax +41 22 727 05 50
[email protected] | www.e-xpertsolutions.com
Quiz !
Solutions à la clef
Quiz!
Describe Secret-Key ? Advantages / Disadvantages
Describe Public-Key ? Advantages / Disadvantages
Describe Messages Digest ? Describe Digital Signature and verification ? Differences between MAC and signature? Describe two Hybrid Cryptosystems ? Describe a challenge response based
authentication?
e-Xpert Solutions SA | 29, route de Pré-Marais | CH 1233 Bernex-Genève | Tél +41 22 727 05 55 | Fax +41 22 727 05 50
[email protected] | www.e-xpertsolutions.com
PKI Introduction
Solutions à la clef
PKI introduction
The aim of PKI is to integrate all the previous mechanisms and algorithms into a coherent and efficient structure.
It will answer the following fundamental security needs:
Authentication Confidentiality Non-Repudiation Integrity
The basis of PKI relies on the concept of certificates
Solutions à la clef
PKI basis function
PKI will include at least: One Certificate Authority who delivers certificates One Directory who stores active Certificates and/or
Revoked Certificates One Registration Authority who allows certificates’
enrollment One centralized Management
Solutions à la clef
Remember Alice, Bob and Charlie...
Bob has no proof of the “link” between Alice’s public-keys and her identities
So What ?
Solutions à la clef
Third Trusted Party
Implicit Trust
No more Charly
Trusted Authority
Direct Trust Direct Trust
Solutions à la clef
Digital Certificates
A public-key certificate is a bond betweenn an entity’s public-key and one entity
The entity can be: A person A role (Manager Director) An organization A piece of hardware (Router, Server, IPSEC, SSL, etc.) A software process (JAVA Applet) A file (Image, Databases, etc.) etc.
Solutions à la clef
Digital Certificates
A Public-key certificate provides assurance that the public-key belongs to the identified entity
A Public-key certificate is also called a digital certificate, digital ID or certificate
The entity identified is referred to as the certificate subject
If the certificate subject is a person, it is referred to as a subscriber
Solutions à la clef
Digital Certificates
A certificate is like a passport ...
Solutions à la clef
How to obtain a certificate
As with passports, you give proof of your identity to an official (or trusted) authority.
The authority checks this proof. The authority delivers a signed passport . This procedure is defined as an “enrollment” Instead of “enrolling” for a passport we’ll enroll
for digital certificate.
Solutions à la clef
Digital Certificates
Graphical representation of a certificate
Solutions à la clef
Demo: certificate view
Solutions à la clef
X.509 Certificate Standard
X.509 is a standard for digital certificate by International Telecommunications Union (ITU)
First published in 1988 (V1.0) Version 2.0 (1993) adds two new fields Current version is v3.0 (1996) and allows
additional extension fields
Solutions à la clef
X.509 Basic Certificate Fields
Version: X509 version 1,2 and 3 Certificate serial number: Integer assigned by
the CA (unique) Signature algorithm identifier: RSA/MD5 etc. Issuer name: name of CA having signed and
issued the certificate Validity period: time interval Subject name: the entity name (this name must
be unique = distinguished name (DN) )
Solutions à la clef
X.509 Basic Certificate Fields
Subject public-key information: contains the public-key plus the parameters
Issuer unique identifier: optional field Subject unique identifier: optional field Extensions: may provide additional data for
specific applications.
Solutions à la clef
How to build a Certificate
CA’sSignature
X.509Fields
Public keyIdentity
etc.
DigitalSignatureProcess
CA
X.509Certificate
Solutions à la clef
How to verify a certificate ?
Obtain the Signer’s (CA) public-key Pass the X.509 fields into the message digest
algorithm and keep the digest (= your digest 1) Decrypt the Certificate signature with the
Signer’s (CA) public-key. The decrypting plaintext will be the digest (= your digest 2)
Compare the digest 1 with the digest 2 Does this match together?
Solutions à la clef
Verifying a certificate?
MD1 = MD2 ???MD1 = MD2 ???CA’sSignature
X.509Fields
Public keyIdentity
etc.
CA’s public keyCA’s public key
Solutions à la clef
A few words about CAs
Entities that issue and manage digital certificates including
maintaining revoking publishing status information
CAs’ security policy defined in CPS (Certification Practice Statement)
Security measures to guarantee CA’s integrity Security measures to check enrollment’s identity
Trust level relies upon CPS and not technology
Solutions à la clef
Few words about CAs
PKI security relies on CA’s private-key secrecy Should never be acceded Should be backed-up Solution: store it inside dedicated tamperproof
hardware
Solutions à la clef
Type of CAs
Private CAs: Hold by a private entity (Company, Administration, the
Military) Public CAs:
Verisign, Swisskey, GTE, Thawte, Global-sign, Certplus, etc.
Solutions à la clef
Registration Authority (RA)
A Registration Authority is the entity receiving the certification requests and managing them before sending them to the CA. RA acts as a front end.
As in hybrid CAs, the registration authority can be separate from the CA itself. In this case we talk about Local Registration Authority (LRA)
Multiple sites for big companies Distributed environment
Solutions à la clef
LDAP
X.500 Directories required more effort and complexity than most companies were prepared to invest
Lightweight Directory Access Protocol was proposed by the Internet community
LDAP uses the X.500 naming conventions but simplifies the way you interact with a directory
Solutions à la clef
LDAP
LDAP is a “front end” that is used to implement simple directory services
An LDAP Server may be implemented over: a full X.500 Directory a database a flat file Most of structured data set
CA will use LDAP to publishcertificates and CRLs
Solutions à la clef
Certificate Revocation
Certificate Revocation: Mechanism used by the CA to publish and disseminate
revoked certificates Revocation is triggered in the following cases:
Key compromise CA compromise Cessation of operation Affiliation change etc...
Solutions à la clef
Certificate Revocation
Several data structures exist to publish revocation
CRL (Certificate Revocation List) ARL (Authority Revocation List) CRT (Certificate Revocation Trees) by Valicert
Also Online query mechanisms OCSP (Online Certificate Status Protocol)
Solutions à la clef
CRL’s publication and retrieval
Certificate-using applications must be aware of revoked certificates
Get CRL via ldap Get CRL via FTP, Http, Https, etc. Check certificate status via OCSP Etc.
Problem to solve: Revocation delay ! Not yet fully standardized (Delta CRLs, OCSP
etc.)
Solutions à la clef
OSCP
OCSPResponder
CA
Backend
LDAP
OCSP
FTP, http
others
OCSP overhttp
PKI enableApplications
Pushing Revocation
Solutions à la clef
Trust
Because a CA has a certificate itself and represents the highest possible trust level, the CA has its self-signed certificate
A self-signed certificate is a Root Certificate or Meta-Introducer
A certificate-using application (any X.509 holders) must trust the Root certificate
Importing a Root certificate into such an application is called Bootstrapping a CA
Solutions à la clef
Trusted Root certificates
Many applications (as http browsers) have already embedded root certificates
Solutions à la clef
Let’s be practical!
User enrolls for certificate
http://www...http://www...
User mailed retrieval PIN
User retrieves certificate
http://www...http://www...
Admin Approves request
http://www...http://www...
User mailed acknowledgement
Admin mailed notification
RA
CA
User
SecurityOfficer
LDAP
Certificate installed
Solutions à la clef
PKI Standards
Some standard organizations: IETF PKI Working Group (PKIX) ITU SPKI RSA with PKCS
Solutions à la clef
PKI Summary
Based on Certificates (X.509) Trusted third party (CA) (L)RA CRL Data repositories Mechanisms and protocols between all these
elements
e-Xpert Solutions SA | 29, route de Pré-Marais | CH 1233 Bernex-Genève | Tél +41 22 727 05 55 | Fax +41 22 727 05 50
[email protected] | www.e-xpertsolutions.com
S/MIME
Solutions à la clef
S/MIME
Secure Multipurpose Internet Mail Exchange Developed by RSA, Microsoft, Lotus, Banyan,
and Connectsoft in 1995 Implemented at application layer Build on top of PKCS #7 and PKCS #10 Very strong commercial vendor acceptance
Netscape, Microsoft, Lotus, etc. IETF developed S/MIME v3 (last version) Use X.509 certificates
Solutions à la clef
S/MIME
S/MIME provides four services:
Security Services Security Mechanism
Message origin authentication Digital Signature
Message integrity Digital Signature
Non-repudiation of origin Digital Signature
Message confidentiality Encryption
Solutions à la clef
S/MIME Ciphers
Symmetric encryption 3DES 168 bit DES 56 bit RC2 128, 64 and 40 bit
Public-Key RSA 512 to 1024 bit
Solutions à la clef
S/MIME dual Key ?
Dual Key Pair One key pair for encryption One key pair for signature and non repudiation
CA must support key backup and recovery Key pair for encryption generated on the CA
itself ! Draw back:
Not all Email client support Dual Key Pair
e-Xpert Solutions SA | 29, route de Pré-Marais | CH 1233 Bernex-Genève | Tél +41 22 727 05 55 | Fax +41 22 727 05 50
[email protected] | www.e-xpertsolutions.com
SSL / TLS
Solutions à la clef
SSL
Secure Sockets Layer TCP/IP socket encryption Provides end-to-end protection of
communications sections Confidentiality protection via encryption Integrity protection with MAC’s Usually authenticates server using a digital
signature (option) Can authenticate client (option)
Solutions à la clef
SSL History
SSL v1 designed by Netscape in 1994 Netscape internal usage
SSL v2 shipped with Navigator 1.0 and 2.0 Microsoft proposed PCT (Private Communications
Technology), which overcame some SSL v2 shortcomings
SSL v3 latest version The progresses of PCT were echoed in SSL v3
TLS v1 developed by IETF
Solutions à la clef
SSL Protocol
The SSL protocol runs above TCP/IP The SSL protocol runs below higher-level
protocols such as HTTP or IMAP
Solutions à la clef
SSL Ports from IANA
nsiiops 261/tcp # IIOP Name Service over TLS/SSL https 443/tcp # http protocol over TLS/SSL smtps 465/tcp # smtp protocol over TLS/SSL (was ssmtp) nntps 563/tcp # nntp protocol over TLS/SSL (was snntp) imap4-ssl 585/tcp # IMAP4+SSL (use 993 instead) sshell 614/tcp # SSLshell ldaps 636/tcp # ldap protocol over TLS/SSL (was sldap) ftps-data 989/tcp # ftp protocol, data, over TLS/SSL ftps 990/tcp # ftp protocol, control, over TLS/SSL telnets 992/tcp # telnet protocol over TLS/SSL imaps 993/tcp # imap4 protocol over TLS/SSL ircs 994/tcp # irc protocol over TLS/SSL pop3s 995/tcp # pop3 protocol over TLS/SSL (was spop3) msft-gc-ssl 3269/tcp # Microsoft Global Catalog with LDAP
Solutions à la clef
SSL Ciphers
The SSL protocol supports the use of a variety of different cryptographic algorithms or ciphers
DES (56) 3DES (168) RC4 (40 or 128) RC2 (40) Fortezza (96) IDEA (128) SHA-1, MD5 DSA RSA (Key exchange)
Solutions à la clef
SSL Handshake
Negotiate the cipher suite Establish a shared session key Authenticate the server (Optional) Authenticate the client (Optional)
Solutions à la clef
SSL Handshake
TCP
Hello
GET URL
Client Server
DATA
Client performs TCP handshake with the server at port 443 for HTTPS which is HTTP in SSLClient performs TCP handshake with the server at port 443 for HTTPS which is HTTP in SSL
Start Cipher negotiation. Client sends SSL HELLO containing ciphers supported by the client and a random number.
Start Cipher negotiation. Client sends SSL HELLO containing ciphers supported by the client and a random number.
Start pass secret. Server sends it’s CERTIFICATE. Start pass secret. Server sends it’s CERTIFICATE.
Client and Server exchange CHANGE CIPHER SPEC and FINISH messages.Client and Server exchange CHANGE CIPHER SPEC and FINISH messages.
Begin bulk encrypted data exchange. Client encrypts and sends HTTP GET.Begin bulk encrypted data exchange. Client encrypts and sends HTTP GET.
Server decrypts request, encrypts and sends responseServer decrypts request, encrypts and sends response
Server sends FINISH and closes with TCP handshakeServer sends FINISH and closes with TCP handshake
S
Bulk EncryptedHTTP ProtocolSymmetric
A SSL connection consists of an SSL handshake followed by bulk encrypted protocolA SSL connection consists of an SSL handshake followed by bulk encrypted protocol
SSLHandshakeAsymmetric0.2 - 4 KB
S
443
Cert
The server responds with a HELLO containing the ciphers to use and a random number. Note the server selects the ciphers to be used. RSA, RC4 and MD5 are most common.
The server responds with a HELLO containing the ciphers to use and a random number. Note the server selects the ciphers to be used. RSA, RC4 and MD5 are most common.
Client uses certificate to encrypt the pre-master Secret and sends to Server. Both compute bulk encryption KEYS from secret and random numbers.
Client uses certificate to encrypt the pre-master Secret and sends to Server. Both compute bulk encryption KEYS from secret and random numbers.
Solutions à la clef
Client authenticate server
Is today's date within the validity period?
Is the issuing CA a trusted CA? Does the issuing CA's public-
key validate the issuer's digital signature?
Does the domain name in the server's certificate match the domain name of the server itself?
Solutions à la clef
Demo: Wrong URL !
Solutions à la clef
Server authenticate client
Does the client's public-key validate its digital signature ? (challenge)
Is today's date within the validity period?
Is the issuing CA a trusted CA? Does the issuing CA's public-
key validate the issuer's digital signature?
Is the user's certificate listed in a CRL?
Solutions à la clef
SSL Tunneling
SSL can provide tunneling to transport TCP port over an encrypted channel
Some tunneling software can use client and server authentication using Certificates X.509
Some tunneling programs Webtop (Sun/Netscape) Stunnel bjorb, Jonama SSLProxy Celo Communicationss (SSR)
Solutions à la clef
SSL Hardware accelerator
RSA key exchange is very CPU Intensive 200 Mhz NT box allows about a dozen concurrent SSL
handshakes Use Multiple server Use Hardware encryption (Intel-IPIVOT, Ncipher, Rainbow,
etc.)
Solutions à la clef
SGC
Server Gated Cryptography Allows strong encryption on a server basis Originally available only to “qualified financial
institutions” Requires a special SGC server certificate from:
Verisign Global-ID Thawte SuperCert GlobalSign HyperSign128 Etc.
Solutions à la clef
SGC
Enables strong encryption for export’s browser Procedure:
Browser is export version: 40 bit cipher only ! Browser connect to SGC-enabled server with 40 bits
cipher Server send his SGC-tagged certificate to browser Browser verifies server certificate and detect that is
issued by a CA root certificate which is tagged to enable SGC
Browser enabled 128 bit ciphers and force a SSL/TLS renegotiation with the stronger cipher suite.
Solutions à la clef
TLS
Transport Layer Security IETF standardized evolution of SSL v3
Update Mac layer to HMAC Updated for newer algorithms
Substantially similar to SSL v3 Cleanup of SSL v3 Aka SSL v3.1
Standardized by RFC 2246 (Jan 1999)
Solutions à la clef
Installing a SSL Web Server
Create the key-pair: Public and Private-Keys Each server includes programs to generate these
Generate a CSR (Certificate Signing Request) This adds Information about your server and yourself
Send the CSR to a CA (Certificate Authority) and wait for your Certificate
For instance Verisign, or a internal CA Install the Certificate
Solutions à la clef
Demo: unknown certificate
e-Xpert Solutions SA | 29, route de Pré-Marais | CH 1233 Bernex-Genève | Tél +41 22 727 05 55 | Fax +41 22 727 05 50
[email protected] | www.e-xpertsolutions.com
IPSEC
Solutions à la clef
IPSec introduction
Stands for IP Security Provide site-to-site and/or host-to-site
encryption and/or authentication Driven by the IETF Mandatory for IPv6, optional for IPv4
Solutions à la clef
IPSec: two main ”Blocks”
IPSec deals with two main “blocks” IPSec - Encryption and Authentication
ESP - Encapsulating Security Payload AH - Authentication Header Two modes: Tunnel and transport
IPSec - Key management IKE, Skip, Manual IPSEC
Solutions à la clef
IPSec: ESP and AH
The AH (Authentication Header) is a protocol providing authentication only
The ESP (Encapsulation Protocol) is an IPSEC protocol for packet encryption and encapsulation.
Both protocols offer integrity check with authentication
Solutions à la clef
IPSec Tunnel mode
Each datagram is captured by the security gateway, encapsulated inside an IPSEC packet and sent to a remote security gateway, which “decapsulates” it, and sends the original datagram to its original destination
The two security gateways create a ‘tunnel’ through which data is passed
The two hosts (and their applications) are unaware of the encapsulation process
Solutions à la clef
IPSec Tunnel mode
IP
TCP
Application
UDP
IP
TCP
Application
UDP
IP
AH/ESP
ProtectedData
IP
AH/ESP
ProtectedData
Protected Traffic
HostsIPSec
gateway
Solutions à la clef
IPSec Transport mode
In transport mode, the two hosts serve as a security gateway and encrypt their own data
In this case, there is no need for a tunnel, nor for the double IP header
The two hosts are aware of the encapsulation (since they perform it)
Solutions à la clef
Transport mode
Protected Traffic IP
TCP
Application
UDP
IP
TCP
Application
UDP
Solutions à la clef
Security Associations (SA)
The SA is shared by the two communicating parties - it provides indications on the algorithms, the keys, the lifetimes and other algorithm dependant information
The SPI (Security Parameter Index) is a number and serves as an index to the SA
Each SA has two SPIs: incoming & outgoing
Solutions à la clef
SPI and SA (Basics)
SPI: 0x1234567
Encryption (ESP): DES
Authentication (AH): SHA-1
DES Key: 0x1615613651365365326536
SHA-1: 0x32676362736347672672644
SPI:0x1234567
SA
Solutions à la clef
IPSec Key management
In order to create the SA, the two parties need to exchange all the security parameters, as well as the keys.
Several methods of key management: Manual keying or manual IPSec (statically defining SPI
and SA). SKIP (Simple Key Interchange Protocol by SUN
Microsystems) ISAKMP/OAKLEY or IKE: automatic key management
using DH Photuris alternative to IKE using DH
Solutions à la clef
Manual IPSec
On each gateway a specific SA is defined (according S/WAN) for each remote gateway (SPI, Cipher, Keys, Hash etc.)
Drawback: Very heavy management Static keys: less security
Often used between different IPSec vendors Cisco to Check Point for instance
Solutions à la clef
Manual IPSec
SA
SPI
SA
SPI
Solutions à la clef
IKE Key management
IKE is widely used (OSPF, IPSec etc..) SA proposal and negotiation is done using IKE Peers may be authenticated using X.509
certificate Each IPSec gateway holds a X.509 certificate SA negotiation starts after cross authentication
Alternate method for authentication: Authentication is provided by pre-shared secrets Drawback: heavy key management etc.
Solutions à la clef
IKE Key management using PKI
SA
SPI
SA
SPI
Negotiation with Automatic
Key Management
X509X509
e-Xpert Solutions SA | 29, route de Pré-Marais | CH 1233 Bernex-Genève | Tél +41 22 727 05 55 | Fax +41 22 727 05 50
[email protected] | www.e-xpertsolutions.com
Questions?
e-Xpert Solutions SA | 29, route de Pré-Marais | CH 1233 Bernex-Genève | Tél +41 22 727 05 55 | Fax +41 22 727 05 50
[email protected] | www.e-xpertsolutions.com
Pour plus d’informations
e-Xpert Solutions SASylvain Maret
Route de Pré-Marais 29CH-1233 Bernex / Genève
+41 22 727 05 [email protected]