grenoble inp ensimag 5mmssi – 3.2. cryptography – some ...pki - definition • hardware,...

5MMSSI – 3.2. Cryptography – some applications

•  Lecturers: Fabien Duchene, Karim Hossen

5MMSSI

2011-2012

Grenoble INP Ensimag

Summary

•  Asymmetric encryption •  Public Key Infrastructure •  SSL •  Digital Rights Management

•  Symmetric encryption •  802.11 – Wifi •  Kerberos

5MMSSI - Information System Security - 2011-2012 2

3.1.1. Public Key Infrastructure

3 5MMSSI - Information System Security - 2011-2012

•  Defintion •  Components •  Certification Authority •  Chain of trust •  Certificate issuance •  Revocation •  Example •  PKCS •  Implementation & use cases

Fabien Duchene, Introduction to the Microsoft PKI Active Directory Certificate Services 2008 R2, Sogeti-ESEC

PKI - definition

•  Hardware, software, people, policies and procedures to manage the lifecycle of digital certificates

o  (manage, distribute, use, store and revoke)

•  It uses: asymmetric cryptography o  … and is ONE solution to associate certificates with identity =

hierarchical model o  … other models exist:

–  local trust model (eg: SPKI) –  web of trust (eg: PGP)

4

X«C» X«A» Z«B»

V

W

X

C A B

Z

Y

U

TISO3960-94/d04

U«V»V«U»

V«W»W«V»

W«X»X«W»X«Z»

Y«Z»Z«Y»Z«X»

V«Y»Y«V»

Figure 4 – CA hierarchy – A hypothetical example5MMSSI - Information System Security - 2011-2012

PKI - components

5

Keys and cer+ficates management tools, audi+ng…

Cer$ficate publica$on and revoca$on distribu$on points

(CRL, OCSP)

Cer$fica$on Authority (CA)

Cer$ficate(s) Requestors (computer, user)

URLs hBp:// file:// ldap://

Security policy

Cer+ficate enrollment and Revoca+on policy

authen+ca+on

Iden$ty Provider (eg: ADDS)

Applications and services .. able to interact with certificates

5MMSSI - Information System Security - 2011-2012

Certification Authority

•  A trusted party (server), as part of a PKI: •  Verify the identity of a certificate requestor •  Issue certificates to requestors (users, comp)

according to the issuance policy •  Manage certificate revocation*

6

*revocation: designing a certificate as no more valid, even if its expiration date is future.

4MMSR - Network Security - 2010-2011 5MMSSI - Information System Security - 2011-2012

Sheldon Cooper

Kim Cameron

Issued certificate

GeekCompany Root CA

PKI – Trust topology

7

•  A hierarchical trust model: – Users/computers trust the Root CA – Transi+ve trust rela+on +ll the leafs

I trust that Root CA

… thus I also trust these CA (issued cert. by the Root CA)

… thus I also trust the identity of that

user/comp (issued cert..)


Certificate insuance

•  A Root CA self-signs its certificate •  The most common model: the requester generates the

KeyPair o  Certificate template: set of parameters (key length, authentication

requirements (1/2/3 factor(s)), permissions…

8

Authenticated Certificate request (public key, validity, certificate template…) 3

2 KeyPair generation (according to the chosen certificate template parameters)

0 Authentication 1

Certificate Templates fetching


Certificate 6

Verifications (template parameters)

4

Certificate issuance (see next slide)

5

Identity Provider

Certification Authority

Certificate Template store

Client

Chain of trust & certificate issuance

•  Trust hierarchy: trusting the Root CA •  Signature: each CA signs all issued certificates

•  … including the child PKI ones!


Chain of trust - signature

10

Clear text cer+ficate informa+on

Thumbprint computation

Thumbprint signed with the issuing CA private key

* hash: function that takes a block of data and returns a fixed size byte element (eg: MD5, SHA-1, SHA-512…)

Cert. Signature field


How could the “chain of trust” be broken?

•  For any certificate in that chain:

•  Validity time: certificate expired? •  Subject name: the certificate information is different to

what the application expects? (eg: loading an https website by its IP, instead of FQDN)

•  Revocation: has that certificate been revoked at the CDP?

•  … and of course if the Root CA of that chain is not trusted!


•  CRL (Certificate Revocation List) •  List of revocated certificates hashes periodically fetched

•  OCSP (Online Certificate Status Protocol) •  Real-Time web request

Certificate hash

  The certificate is not trusted

  The certificate is trusted

yes

no Periodical CRL download (HTTP, SMB, LDAP…)

PKI - Revocation

14

Certificate hash

  The certificate is not trusted

  The certificate is trusted

yes

no

Is the certificate revoked?

OCSP Request

OCSP signed Reply

Is the hash present in the signed CRL? (by the issuing CA)


PKI – certificate verification example •  Consider the following scenario:

18

Should I trust the customer CA

certificate, knowing I obtained the Root CA

cert from the AIA?

0. Get the AIA information periodically (URL, download the Root CA public key)

3. Is the Root CA cert. revoked or expired? (CRL, OCSP) Is it the right computer (DNS FQDN)?

1. The Customer CA is presenting us its certificate (…and the related chain of

trust)

2. Do I trust the Root CA certificate? (“Trusted Root

Certification Authorities”?)

4. Check the Ext. Pol. CA certificate signature (parent CA)

5. 6. 7. 8. …


6.4.7. PKI - PKCS

•  Public-Key Cryptography Standards •  Based on Diffie & Hellmann research (1976)

asymetric crypto •  OS neutral •  Used in many standards relying on asymetric crypto


•  PKCS #1: RSA Encryption Standard •  PKCS #3: Diffie-Hellman Key-

Agreement Standard •  PKCS #5: Password-Based

Cryptography Standard •  PKCS #6: Extended-Certificate Syntax

Standard •  PKCS #7: Cryptographic Message

Syntax Standard •  PKCS #8: Private-Key Information

Syntax Standard

•  PKCS #9: Selected Attribute Types •  PKCS #10: Certification Request

Syntax Standard •  PKCS #11: Cryptographic Token

Interface Standard •  PKCS #12: Personal Information

Exchange Syntax Standard •  PKCS #13: Elliptic Curve

Cryptography Standard •  PKCS #15: Cryptographic Token

Information Format Standard

Some implementations & use cases

•  Web-Security •  SSL: website authentication and data encryption •  Email signature and encryption

•  Corporate security •  2 factors authentication

•  Application/Data integrity •  Java Applets •  Apple iOS applications •  Microsoft Windows updates •  Antimalware signatures

•  Data confidentiality and access control: DRM

22 4MMSR - Network Security - 2010-2011 5MMSSI - Information System Security - 2011-2012

3.1.2. Secure Socket Layer “SSL” / TLS


•  SSL 1.0: Netscape, 1995 ; TLS = Transport Security Layer •  Current version: TLS 1.2 (aka SSL 3.3), RFC5248 aug 2008 •  Security properties

o Communication: –  Integrity (MAC) –  Confidentiality (symmetric cryptography)

o Server: authentication (asymmetric crypto) o Key exchange (RSA, Diffie-Hellman…) o Eventually client authentication

•  Sub-protocols o Handshake: version, algorithm, authentication o Record: data fragmentation (app. layer), integrity, confidentiality o Alert: errors, end of session o ChangeCipherSpec: messages will be authenticated (and eventually encrypted)

o Application: application data

Applica$on HTTP, FTP, SIP, IMAP, POP…

SSL/TLS

TCP

5.5. SSL handshake (unauthenticated client)


Client

1.1 ClientHello (ciphers and compression it supports, ClientNonce)

Server

1.3

1.3.1. ServerHello (chosen TLS version, cipher, compression, and a ServerNonce) 1.3.2. Certificate 1.3.3. ServerHelloDone

1.5 ClientKeyExchange (PreMasterSecret encrypted using K_server_pub) Eventually sends the serverNonce encrypted with K_client_priv

1.4 ServerCertificate validation (integrity, validity time, revocation)

1.2 Cipher and compression choice

1.6 Decryption of the PreMasterSecret (using K_Server_priv)

Session_keys = function(PreMasterKey,ClientNonce,ServerNonce) 1.7 1.7

1.8 1.8.1. ChangeCipherSec (next messages will be authenticated and encrypted) 1.8.2. Finished = hash(prev_msgs) ; MAC(session_key, prev_msgs)

1.9 1.9.1. ChangeCipherSec 1.9.2. Finished = hash(prev_msgs) ; MAC(session_key, prev_msgs)

MAC = Message Authentication Code ; hash_function(key, message)

3.1.3. Digital Rights Management


•  Symmetric and asymmetric! •  Permits a just-in-time use control (read, copy,

modify…) on data •  Data_i is encrypted (K_data_i), symmetric •  Each time an application wants to access data_i, it has

to request the decryption key to a server E(K_data_i, K_client_pub)

•  Generally done over an encrypted channel (eg: SSL) •  The decryption key is thrown away afterwards

DRM: an attack


•  An attack: steal the decryption key in memory •  only works for 1 file •  Might not be that simple (eg: evolving code, need for

reverse engineering) •  Examples:

•  Apple music, video (when read on itunes) •  Microsoft Encrypted FileSystem

3.2.1. 802.11 - Wifi


•  802.11 security •  802.11 •  RC4 •  WEP •  SKA

•  WPA •  802.11i

•  WPA2 •  802.11 security in corporations

802.11


•  802.11: a (1999), b(1999), g(2003), n (2009) •  Review your network courses •  Security (1999):

•  Data encryption: Wireless Equivalent Privacy “WEP” •  Authentication:

o  Shared Key Authentication “SKA” (WEP is used during authentication)

o  Open System Authentication (no authentication occurs)

Reminder: RC4


•  stream cipher •  IV: Initialisation Vector •  Key (shared between the parties)

•  Flaws: (ability to gain some knowledge about the key) •  same IV is used •  Weak number generator weak

Wikipedia-WEP

Weaknesses in the Key Scheduling Algorithm of RC4, Scott Fluhrer, Itsik Mantin, Adi Shamir

Wireless Equivalent Privacy "WEP"


•  Chiffre = RC4 – 56 bits •  IV : 24 bits

•  802.11 does not prevent reusing the same IV!! •  Key = “WEP password”

•  40 bits (40+24= “64 bits WEP security”) •  104 bits (“128 bits WEP security”)

•  ICV : Integrity Check Value : CRC-32

•  clear-text frame:

•  WEP-encrypted frame:

802.11 header 802.11 payload

802.11 header

Encrypted data IV ICV

Chiffré

Shared Key Authentication “SKA”


•  Four Way Handshake using the WEP password (secret key)

Client station Access Point

Authentication-request 1

shared secret key (WEP password)

shared secret key (WEP password)

RAC4(challenge, WEP key) 3

Positive / negative response 4

-‐-‐-‐ Challenge decryption and comparison

clear-text challenge 2

RC4 problem – Vernam cipher


•  if real randomness, then one-time pad

•  What if r is not so random?...

Secret Key KE

Pseudo Random Number Generator

Unencrypted data d

Encrypted data e = d XOR r

XOR

Random number r

Stream cipher: basic cryptanalysis


•  What if the same encryption key is used at least two times? •  e1=d1 XOR r •  e2=d2 XOR r •  Then: e1 XOR e2 = d1 XOR d2

•  From that we can deduce: •  reusing r is a VERY bad idea •  d1 and d2 are not random (thus sensible to

“patterns attacks”. See aircrack (ARP attacks)) •  802.11

o  ICV (CRC) could confirm we did find the value! o  “r” is IV+wep_password

the Birthday paradox with 802.11 IVs


•  Pn: probability that 2 packets among n do use the same IV •  IV: 24 bits ; thus number of IV = 2^24 •  P2 = 1/(2^24) •  Pn = Pn–1 + (n – 1)(1 – Pn–1)/(2^24) (n>2) •  Pn = 1 – (1-1/(2^24))^(n(n-1)/2)

•  Pn >= 50% •  Starting from only n=4823 packets!

WEP security?


•  Attacking WEP only takes ~ 3 minutes •  aircrack-ng (original work, Christophe Devine)

•  Consequences •  Ability to modify the packets (integrity loss) •  Ability to authenticate

•  Solutions •  increasing the size of the WEP key (and/or the possible space of

the IV) is not enough (B’day paradox) •  authentication, we could use EAP (see 802.11 WPA2) •  we should rely on another kind of cipher (eg: block cipher, see WPA)

Wifi Protected Access “WPA”


•  Intermediate measures to protect Wifi networks while waiting for full 802.11i specs (aka WPA2) •  2002 •  without changing the hardware! (only requires a ram flash)

•  Authentication and integrity •  Temporary Key Integrity Protocol (TKIP)

o  still RC4 but: 128 bits key/packet o  rekeying mechanism (frequently change, avoiding collisions) o  the ICV field is replaced by

–  a MICHAEL integrity check (64 bits) –  sequence number for each packet (replay protection)

•  AES (block cipher), optionnal o  Mandatory in WPA2

WPA (with TKIP) attacks


•  En novembre 2008 deux chercheurs allemands en sécurité, Éric Tews et Martin Beck, ont annoncé avoir découvert une faille de sécurité dans le protocole WPA. La faille, située au niveau de l'algorithme TKIP (Temporal Key Integrity Protocol), exploite l'architecture du protocole WPA.

•  TKIP se met en place après le protocole WEP, or le code MAC est contenu dans un paquet WEP, ce qui permet à un pirate informatique de l'intercepter. Une fois intercepté le paquet peut être utilisé pour récupérer le code MAC et se faire passer pour le point d'accès. Cette méthode est encore plus efficace en interceptant les paquets ARP puisque leur contenu est connu. (attaques par pattern).Cette faille concerne exclusivement le protocole WPA utilisant TKIP. Les protocoles utilisant AES restent sécurisés.

•  Les détails concernant cette faille ont été exposés de façon détaillée durant la conférence PacSec les 12 et 13 novembre 2008 à Tokyo[2]. Martin Beck a intégré l'outil pour exploiter cette faille dans son outil de piratage des liaisons sans fil, nommé aircrack-ng (createur originel d’aircrack: Christophe Devine).

•  Contre-mesure: Il est toutefois assez facile de contrevenir à cette faille en forçant la négociation des clés toutes les deux minutes ce qui ne laisse pas assez de temps pour que l'attaque réussisse.

802.11i


•  IEEE standard: 802.11-2007 (draft in 2004, amended in 2007) •  WPA2

•  CCMP (Counter-Mode/CipherBlockChaining-Mac Protocol) o AES/FIPS-197 o 128-bit key, 128 bits cipher block o 10 rounds of encoding

•  802.1x support in 802.11 •  Key distribution

802.11 in corporations


•  WPA-enterprise •  WPA2-enterprise

•  EAP for authentication and encryption. Mostly used •  EAP-TLS (with certificates, thus a PKI is needed) •  EAP-TTLS •  PEAP (Microsoft)

XKCD Interlude: random number generator


http://xkcd.com/424/

http://lists.debian.org/debian-security-announce/2008/msg00152.html

3.2.2. Active Directory

•  Active Directory Directory Services: service d’annuaire: •  Ouverture de session unique •  Accès universel aux ressources •  Administration centralisée ou déléguée •  Service d’authentification et de fourniture de données

d’authentification •  Fonctionnalités:

•  Kerberos authentication •  LDAP directory (contains Security Principals & other objects)

•  DNS resolution •  Versions:

•  2000 native, 2000 mixed ; 2003, 2003 R2 ; 2008, 2008 R2 5MMSSI - Information System Security - 2011-2012 49

Rôle de machines Windows

•  Autonome (Workgroup) •  Non membre d’un domaine •  Base de comptes “SAM” (Security Account Manager) locale

•  Client membre (d’un domaine) •  Base SAM locale •  Authentification:

o  domaine o  SAM locale

•  Contrôleur de domaine (DC) •  Copie des objets du domaine •  Assure le rôle KDC dans Kerberos

o  Authentifie les machines et utilisateurs


ADDS – Domaines, Forêts

corp.ensimag.fr

jpn usa

Domain

Tree

Child domain

Root domain

•  Domaine (domain): 1 FQDN DNS, 1 annuaire (security principals, politiques de sécurité), authentification

•  Arbre (tree): hiérarchie de domaines DNS •  Forêt (forest): plusieurs hiérarchies DNS (cf slide suivante)


ADDS – trust relationships “approbations”


•  Trust relationships •  “one-way trust” A<-B: one way (transitive or not) relation

meaning a domain A considers the identities provided by B as valid •  “two-way trust” A<->B = (A<-B) AND (B<-A)

Within a tree: implicit transitive 2-way trust between child and parent

domains

corp.ensimag.fr

jpn usa

“ TRUSTING domain “

domaine.phelma.fr

peru

Example of one-way forest trust: corp.nintendo.com trusts

ms.google.biz tree

“ TRUSTED domain “

Windows NT5+ : quelques protocoles


•  NT5: Windows 2000 •  Protocoles:

•  clé partagés o  Authentification NTLM (domaines hétérogènes) o  Authentification Kerberos V5

•  clé publique o  Secure Sockets Layer (SSL) / transport Layer Security (TLS) o  IPSec

•  Active Directory peut gérer différents types de credentials (SSP)

•  Rôles de machine Windows

Kerberos


•  Protocole authentification, autorisation, développé par le MIT (Projet ATHENA), ~ Single-Sign-On

•  Version actuelle: v5 RFC4120 •  Hypothèse: le réseau peut être non sûr •  Basé sur l’existence d’un tiers de

confiance, le KDC (« Key Distribution Center »

•  Cryptographie •  principlament symétrique •  éventuellement assymétrique (eg:

auth. par carte à puce) •  Déclinaisons:

•  MIT Kerberos •  Microsoft Kerberos, Windows NT

(>=2000) •  Heimdal Kerberos, Suède

Kerberos & Herakles

(Cerbère & Hercules)

Kerberos: authentication & service access


User / computer

Identity provider, Authentication Server

GC

Service Server (eg: issuing CA)

Ticket Grantig Service TGS

1

“I am Mossen. I need a Ticket to Get Tickets” (TGT)

Key Distribution Center (KDC)

Here is a TGT you will only be able to decrypt if you know the shared secret (user/comp. pwd)

2 3

I want to access the “Issuing CA” service. Here is a proof I decrypted the TGT

4 Here is a Service Ticket containing your information for accessing the Issuing CA service

UserSID -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐

GroupMembershipsSIDs

Service Ticket

5

6 Service communication

Introduction to the Microsoft PKI ADCS 2008 R2 (2011), Fabien Duchene, Sogeti-ESEC

Kerberos: authentification du client (1,2)


•  Client_ID: Security Principal Name (username, computername…) •  [msg]key: chiffrement de msg avec la clé key •  K_client: hash du mot de passe du client (user/ comp.) •  K_client-TGS: session key generated by the AS

User / computer


1 1: Client_ID

2.1: [Client-TGS_Session_key], K_client 2.2: “Ticket-to-Get-Ticket” [client_ID, client_FQDN, TGT_validity_period, K_client-TGS]K_TGS

2

Knows: K_client

Knows: K_client K_TGS K_cli-TGS

KDC

Kerberos: autorisation d’accès au service (3,4)


•  TGT= [client_ID, client_FQDN, TGT_validity_period, K_client-TGS]K_TGS •  Req_svc_ID: ID of the service the client requests access to •  K_client-SS: session key for the client and the requested service

Ticket Grantig Service TGS

Knows: K_client K_client-TGS (K_client-SS)

Knows: K_TGS (K_client-TGS) K_req_svc (K_client-SS)

User / computer

KDC

3 3.1: TGT, Req_svc_ID 3.2: “Authenticator” [Client_ID,timestamp]K_client-TGS

4.1: “Client-to-Server ticket”: [client_ID,client_FQDN,TCS_validity_period,K_client-svc] K_req_svc 4.2: [K_client-SS] K_client-TGS

4

Kerberos: accès au service (5,6)


•  Client-to-Server ticket: [client_ID,client_FQDN,TCS_validity_period,K_client-svc] K_req_svc

•  K_client-SS: session key between the client and the SS

User / computer

Knows: K_client K_client-SS

Service Server (eg: issuing CA)

6:[timestamp_in_5.2 + 1]K_client-SS : “OK, I can serve you”

6

5 5.1: “Client-to-Server ticket” 5.2: “Authenticator-2” [Client_ID,timestamp]K_client-SS

7 Is timestamp=timestamp_5.2+1? If so, I can trust that service

Kerberos – Accès inter-domaine


•  Une relation de confiance est établie par le biais d’une clé partagée entre domaines, grâce à laquelle des referals tickets (TGT inter-domaine) sont envoyés

corp.ensimag.fr domaine..phelma.fr

User / comput

er Service Server (eg: issuing CA)

TGS 1

2

AS

3

4 5

6

“ TRUSTING domain “ contains ressources/SS

“ TRUSTED domain “ contains identities

K_AS(google)-TGS(nintendo)

TGT inter-domaine

Kerberos: Smart Card authentication


•  Client_ID: Security Principal Name (username, computername…) •  [msg]key: chiffrement de msg avec la clé key •  K_client_pub,K_client_priv: paire de clé assymétrique •  K_client-TGS: session key generated by the AS

User / computer


1 1: [Client_ID]K_client_PRIV

2.1: [Client-TGS_Session_key], K_client_PUB 2.2: “Ticket-to-Get-Ticket” [client_ID, client_FQDN, TGT_validity_period, K_client-TGS]K_TGS

2

Knows: K_client_PUB K_client_PRIV

Knows: K_client_PUB K_TGS K_cli-TGS

KDC

Kerberos et Windows: API et appels


Kerberos: optimisations


•  Optimisations •  Les tickets et le clés de sessions sont en cache sur le client •  Un mécanisme permet d’obtenir des tickets sans avoir à redonner

son mot de passe o  Ticket-Granting-Ticket (TGT) a faible durée de vie o  Le KDC donne des tickets sur présentation du TGT

•  Paramètres par défaut •  Validité TGT=10H •  Validité TGS= 10H •  Différence de 5 minutes MAX entre client, AS, TGS, SS

synchronisation NTP

Kerberos – some threats and attacks


•  Threats •  single-point of failure: if only one KDC •  impersonation: if at least one KDC compromised. Any user could be

impersonated •  Attacks

•  KDC spoofing: old PAM_KRB5 implementation (no authorization) •  Replay attack: sniff and resend 5. KRB_AP_REP

o  KRB_AP_REP: validity duration (generally 5 minutes), source IP o  Service Server stores a cache of requests. Multiple identitical

KRP_AP_REP are ignored •  Cipher: DES (weak) initially used. Negotiation not authenticated

o  Windows 7: DES disabled for Kerberos authentication •  Ticket cache attack (“file” on the client system) •  Pass the Ticket: ability to authenticate on the client. Only Microsoft

implementation is vulnerable and not yet corrected. Taming the Beast Assess Kerberos-Protected networks, Emmanuel Bouillon, Black-Hat 2009

3.2. Cryptography – some applications - summary


PKI • Asymetric cryptography • Hierarchical Trust model • Cer+fica+on Authority • Cer+ficate, issuance • Signature • Smart Card • Revoca+on CRL

SSL/TLS • Btwn transport and applica+on layer • Cer+ficate (server, eventually client) • Handshake

DRM • Use control on data (eg: video, audio…): read, copy, modify… • Each access a decryp+on key is requested to the server • Each data encrypted with a symmetric algorithm using a different key

802.11 • WEP: RC4 stream cipher • WPA: adds TKIP, not enough • WPA2: AES block cipher • Corpora+ons: WPA(2)-‐enterprise ; mostly EAP-‐TLS

Ac+ve Directory • Features • LDAP • DNS • Kerberos • Authen+ca+on • ACL on objects

Kerberos (MS implementa+on) • Symetric cryptography • Single-‐Sign-‐On • Client wants to access a Service • Trusted 3rd party (KDC) • Asymetric crypto for Smart Card authen+ca+on

grenoble inp ensimag 5mmssi – 3.2. cryptography – some ...pki - definition • hardware,...

Documents