4MMSR 1.2. Cryptography some applications

(1)

4MMSR – 1.2. Cryptography –

some applications

• Lecturer: Fabien Duchene

• Asymmetric encryption

o 1.2.1. Public Key Infrastructure o 1.2.2. SSL

o 1.2.3. Digital Rights Management

• Symmetric encryption

o 1.2.4. 802.11 – Wifi o 1.2.5. Kerberos

4MMSR 2011-2012

(2)

1.2.1. Public Key Infrastructure

2 5MMSSI - Information System Security - _2011-2012

• Defintion • Components • Certification Authority • Chain of trust • Certificate issuance • Revocation • Example • PKCS

• Implementation & use cases

(3)

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)

3 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 example

5MMSSI - Information System Security - 2011-2012

(4)

PKI - components

4

Keys and certificates

management tools, auditing… _{revocation distribution points}Certificate publication and (CRL, OCSP)

Certification Authority

(CA)

Certificate(s) Requestors (computer, user)

URLs http:// file:// ldap:// Security policy

Certificate enrollment and Revocation policy

authentication

Identity Provider

(eg: ADDS)

Applications and services

.. able to interact with certificates 5MMSSI - Information System Security -

(5)

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*

5

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

(6)

Sheldon Cooper Kim Cameron Issued certificate GeekCompany Root CA

PKI – Trust topology

6

• A hierarchical trust model:

– Users/computers trust the Root CA

– Transitive trust relation till 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..)

(7)

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…

7

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

5MMSSI - Information System Security - 2011-2012 Certificate 6 Verifications (template parameters) 4 Certificate issuance (see next slide)

5 Identity Provider Certification Authority Certificate Template store Client

(8)

Chain of trust & certificate

issuance

• Trust hierarchy: trusting the Root CA

• Signature: each CA signs all issued certificates

• … including the child PKI ones!

(9)

Chain of trust - signature

9

Clear text certificate information

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

(10)

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!

(11)

• 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

11 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)

(12)

PKI – certificate verification example

• Consider the following scenario:

12

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

(13)

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

(14)

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

(15)

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

Application

HTTP, FTP, SIP, IMAP, POP…

SSL/TLS TCP

(16)

1.2.2. SSL handshake

(unauthenticated client)

16 5MMSSI - Information System Security - _2011-2012 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 _{Eventually sends the serverNonce encrypted with K_client_priv}(PreMasterSecret encrypted using K_server_pub) 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 _{1.8.2. Finished = hash(prev_msgs) ; MAC(session_key, prev_msgs)}(next messages will be authenticated and encrypted) 1.9 1.9.1. ChangeCipherSec

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

(17)

1.2.3. Digital Rights Management

17

• 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

(18)

1.2.3. 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)

(19)

1.2.4. 802.11 - Wifi

• 802.11 security • 802.11 • RC4 • WEP • SKA • WPA • 802.11i • WPA2 • 802.11 security in corporations

(20)

802.11

• 802.11: a (1999), b(1999), g(2003), n (2009)

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

(21)

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

(22)

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

(23)

Shared Key Authentication “SKA”

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

Client station 1 _{Authentication-request} Access Point

shared secret key (WEP password)

RAC4(challenge, WEP key)

3

Positive / negative response

4 ---

Challenge decryption and comparison

clear-text challenge

(24)

RC4 problem – Vernam cipher

• if real randomness, then one-time pad

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

K_E Pseudo Random

Number Generator

Unencrypted data

d XOR Encrypted data _{e = d XOR r}

Random number r

(25)

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

(26)

the Birthday paradox with 802.11 IVs

• P

n: 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%

(27)

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

• Counter-measures

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

(28)

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), optional

(29)

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.

(30)

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

(31)

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

(32)

XKCD Interlude: random number generator

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

(33)

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

(34)

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

(35)

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)

(36)

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

(37)

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)

(38)

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

(39)

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

(40)

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 Identity provider, Authentication Server 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

(41)

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

(42)

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?

(43)

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)

(44)

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 Identity provider, Authentication Server 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

(45)

Kerberos et Windows: API et appels

(46)

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

(47)

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.

(48)

3.2. Cryptography – some applications -

summary

PKI

•Asymetric cryptography •Hierarchical Trust model •Certification Authority •Certificate, issuance •Signature •Smart Card •Revocation CRL SSL/TLS

•Btwn transport and application layer •Certificate (server, eventually client) •Handshake

DRM

•Use control on data (eg: video, audio…): read, copy, modify…

•Each access a decryption 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

•Corporations: WPA(2)-enterprise ; mostly EAP-TLS Active Directory •Features •LDAP •DNS •Kerberos •Authentication •ACL on objects Kerberos (MS implementation) •Symetric cryptography •Single-Sign-On

•Client wants to access a Service •Trusted 3rd_{party (KDC)}

•Asymetric crypto for Smart Card authentication