5MMSSI 3.2. Cryptography some applications

Transcription

1 5MMSSI Grenoble INP Ensimag 5MMSSI 3.2. Cryptography some applications Lecturers: Fabien Duchene, Karim Hossen

2 Summary Asymmetric encryption Public Key Infrastructure SSL Digital Rights Management Symmetric encryption Wifi Kerberos 2

3 Public Key Infrastructure 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 3

4 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) U«V» V«U» U V V«W» W«V» V«Y» Y«V» Y W W«X» X«W» X«Z» C X«C» Y«Z» Z«Y» Z«X» Z X A X«A» B Z«B» TISO /d04 4 Figure 4 CA hierarchy A hypothetical example

5 PKI - components Keys and cer+ficates Cer$fica$on Authority Cer$ficate publica$on and management tools, audi+ng revoca$on distribu$on points (CA) (CRL, OCSP) Security policy URLs hbp:// file:// Cer+ficate enrollment and ldap:// Revoca+on policy authen+ca+on Cer$ficate(s) Requestors (computer, user) Applications and services.. able to interact with certificates 5 Iden$ty Provider (eg: ADDS)

6 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* *revocation: designing a certificate as no more valid, even if its expiration date is future. 6 4MMSR - Network Security MMSSI - Information System Security

7 PKI Trust topology 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) Sheldon Cooper thus I also trust the identity of that user/comp (issued cert..) Issued certificate Kim Cameron 7 GeekCompany Root CA

8 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 Certificate Template store 1 Certificate Templates fetching 0 Authentication 4 Verifications Authenticated Certificate request 3 (public key, validity, certificate template ) Client KeyPair generation 2 (according to the chosen certificate template parameters) 8 Identity Provider 6 Certificate (template parameters) Certification Authority 5 Certificate issuance (see next slide)

9 Chain of trust & certificate issuance Trust hierarchy: trusting the Root CA Signature: each CA signs all issued certificates including the child PKI ones! 9

10 Chain of trust - signature Clear text cer+ficate informa+on Thumbprint computation Thumbprint signed with the issuing CA private key Cert. Signature field * hash: function that takes a block of data and returns a fixed size byte element (eg: MD5, SHA-1, SHA-512 ) 10

11 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 5MMSSI - Information System Security

12 PKI - Revocation CRL (Certificate Revocation List) List of revocated certificates hashes periodically fetched Periodical CRL download (HTTP, SMB, LDAP ) Certificate hash Is the hash present in the signed CRL? yes no The certificate is not trusted The certificate is trusted (by the issuing CA) OCSP (Online Certificate Status Protocol) Real-Time web request Certificate hash 14 Is the certificate revoked? OCSP Request yes The certificate is no OCSP signed Reply not trusted The certificate is trusted

13 PKI certificate verification example Consider the following scenario: Should I trust the customer CA certificate, knowing I 0. Get the AIA information periodically obtained the Root CA (URL, download the Root CA public key) cert from the AIA? 3. Is the Root CA cert. revoked or expired? (CRL, OCSP) Is it the right computer (DNS FQDN)? 4. Check the Ext. Pol. CA certificate signature (parent CA) The Customer CA is presenting us its certificate ( and the related chain of trust) Do I trust the Root CA certificate? ( Trusted Root Certification Authorities?)

14 PKI - PKCS Public-Key Cryptography Standards Based on Diffie & Hellmann research (1976) asymetric crypto OS neutral Used in many standards relying on asymetric crypto 21 PKCS #1: RSA Encryption Standard PKCS #3: Diffie-Hellman KeyAgreement 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

15 Some implementations & use cases Web-Security SSL: website authentication and data encryption 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 MMSSI - Information System Security

16 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 Applica$on HTTP, FTP, SIP, IMAP, POP SSL/TLS TCP Sub-protocols 23 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) 5MMSSI - Information System Security o Application: application data

17 5.5. SSL handshake (unauthenticated client) MAC = Message Authentication Code ; hash_function(key, message) 1.1 ClientHello (ciphers and compression it supports, ClientNonce) Cipher and compression choice ServerHello (chosen TLS version, cipher, compression, and a ServerNonce) Certificate ServerHelloDone 1.4 ServerCertificate validation (integrity, validity time, revocation) 1.5 ClientKeyExchange (PreMasterSecret encrypted using K_server_pub) Eventually sends the servernonce encrypted with K_client_priv Decryption of the PreMasterSecret (using K_Server_priv) Session_keys = function(premasterkey,clientnonce,servernonce) 1.7 Client ChangeCipherSec (next messages will be authenticated and encrypted) Finished = hash(prev_msgs) ; MAC(session_key, prev_msgs) ChangeCipherSec Finished = hash(prev_msgs) ; MAC(session_key, prev_msgs) 25 Server 1.9

18 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 26

19 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 27

20 Wifi security RC4 WEP SKA WPA i WPA security in corporations 28

21 : 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) 29

22 Reminder: RC4 stream cipher IV: Initialisation Vector Key (shared between the parties) Wikipedia-WEP Flaws: (ability to gain some knowledge about the key) same IV is used Weak number generator weak Weaknesses in the Key Scheduling Algorithm of RC4, Scott Fluhrer, Itsik Mantin, Adi Shamir 31

23 Wireless Equivalent Privacy "WEP" Chiffre = RC4 56 bits IV : 24 bits 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 clear-text frame: header WEP-encrypted frame: header payload IV Encrypted data ICV Chiffré

24 Shared Key Authentication SKA Four Way Handshake using the WEP password (secret key) Client station 1 Authentication-request clear-text challenge 3 shared secret key (WEP password) 2 RAC4(challenge, WEP key) Challenge decryption and comparison Positive / negative response 33 Access Point shared secret key (WEP password)

25 RC4 problem Vernam cipher if real randomness, then one-time pad Secret Key KE Pseudo Random Number Generator Random number r Unencrypted data d XOR What if r is not so random? Encrypted data e = d XOR r

26 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)) o ICV (CRC) could confirm we did find the value! o r is IV+wep_password 36

27 the Birthday paradox with 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! 37

28 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 WPA2) we should rely on another kind of cipher (eg: block cipher, see WPA) 40

29 Wifi Protected Access WPA Intermediate measures to protect Wifi networks while waiting for full i 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 43

30 WPA (with TKIP) attacks 44 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.

31 802.11i IEEE standard: (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 Key distribution 45

32 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) 46

33 XKCD Interlude: random number generator

34 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 49

35 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 50

36 ADDS Domaines, Forêts 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) Tree corp.ensimag.fr jpn Domain 51 usa Root domain Child domain

37 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 2way trust between child and parent domains corp.ensimag.fr jpn usa TRUSTING domain 52 Example of one-way forest trust: corp.nintendo.com trusts ms.google.biz tree domaine.phelma.fr peru TRUSTED domain

38 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 55

39 Kerberos Kerberos & Herakles (Cerbère & Hercules) 56 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

40 Kerberos: authentication & service access Key Distribution Center (KDC) Identity provider, Authentication Server Ticket Grantig Service TGS GC I am Mossen. I need a Ticket to Get Tickets (TGT) 1 User / computer 4 2 Here is a Service Ticket containing your 3 Here is a TGT you will only information for accessing I want to access the be able to decrypt if you Issuing CA service. the Issuing CA service know the shared secret Here is a proof I (user/comp. pwd) decrypted the TGT 5 Service Ticket UserSID GroupMembershipsSIDs 6 Service communication 57 Service Server (eg: issuing CA) Introduction to the Microsoft PKI ADCS 2008 R2 (2011), Fabien Duchene, Sogeti-ESEC

41 Kerberos: authentification du client (1,2) Client_ID: Security Principal Name (username, computername ) KDC [msg]key: chiffrement de msg avec la clé key K_client: hash du mot de passe du client (user/ comp.) Knows: K_client-TGS: session key generated by the AS K_client K_TGS K_cli-TGS Identity provider, Authentication Server 1 1: Client_ID Knows: K_client 2 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 User / computer 58

42 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 3 3.1: TGT, Req_svc_ID Knows: K_client K_client-TGS (K_client-SS) User / computer : Authenticator [Client_ID,timestamp]K_client-TGS KDC Knows: K_TGS (K_client-TGS) K_req_svc (K_client-SS) Ticket Grantig Service TGS 4 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

43 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 5 5.1: Client-to-Server ticket 5.2: Authenticator-2 [Client_ID,timestamp]K_client-SS Knows: K_client K_client-SS Service Server (eg: issuing CA) 6 6:[timestamp_in_ ]K_client-SS : OK, I can serve you User / computer 60 7 Is timestamp=timestamp_5.2+1? If so, I can trust that service

44 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 TRUSTING domain contains ressources/ss TRUSTED domain contains identities corp.ensimag.fr AS domaine..phelma.fr K_AS(google)-TGS(nintendo) TGS 3 1 TGT inter-domaine Service Server (eg: issuing CA) 5MMSSI - Information System Security User / comput er

45 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 KDC Knows: K_client_PUB K_client_PRIV 1: [Client_ID]K_client_PRIV 1 2 User / computer 65 Knows: K_client_PUB K_TGS K_cli-TGS Identity provider, Authentication Server 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

46 Kerberos et Windows: API et appels 67

47 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 68

48 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

49 3.2. Cryptography some applications summary 70 PKI SSL/TLS DRM Asymetric cryptography Hierarchical Trust model Cer+fica+on Authority Cer+ficate, issuance Signature Smart Card Revoca+on CRL Btwn transport and applica+on layer Cer+ficate (server, eventually client) Handshake 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 Ac+ve Directory Kerberos (MS implementa+on) WEP: RC4 stream cipher WPA: adds TKIP, not enough WPA2: AES block cipher Corpora+ons: WPA(2)- enterprise ; mostly EAP- TLS Features LDAP DNS Kerberos Authen+ca+on ACL on objects Symetric cryptography Single- Sign- On Client wants to access a Service Trusted 3rd party (KDC) Asymetric crypto for Smart Card authen+ca+on