Introduction to Information System Security

Introduction to Information System Security
Access Control Introduction to Information System Security Jean Leneutre Tél.:

Outline I- Introduction II- Definitions
III- Common vulnerabilities and threats IV- Authentication V- Access control

Assumption: Kab is a secret key shared between a and b
IV- Authentication A secure system needs to check the identities of the entities requesting its services: To perform access control To record events in order to be able to audit Authentication is a pre-requisite to ensure the confidentiality / integrity of communications a b {m}kab m {m}kab Encryption {m}kab m Decryption Assumption: Kab is a secret key shared between a and b How to ensure it?

IV- Authentication Entity authentication
Process which permits to an entity A to check the identity of an entity B with whom A is communicating Example: A phones to B, and asks to B a new question (for which only A and B know the answer) Mutual entity authentication: A authenticates B and B authenticates A Delegation of entity authentification: A delegates the authentification of B to a trusted third party (TTA) and accepts the result Prover = entity that tries to be authenticated Verifier = entity that checks the identity of the prover Proof = information used by the prover to prove its identity to the verifier

IV- Authentication Data origin authentication (or message authentication) Process that permits to an entity that receives a message to check the identity of the entity that initially sent the message Example : A receives a mail together with a digital signature whose header « from » is the address of B; A checks the digital signature Implicitly ensures integrity: if the message has been modified during transmission, B is no more the origin of the message No freshness : do not protect against replay of messages

IV- Authentication Types of Proof for entity authentication
Based on knowledge: Password PIN Code (Personal Identification Number) Cryptographic key Based on ownership: Smartcards, USB token Based on biometric properties: Fingerprint, retina, iris, … A reference value is stored and compared with a new capture False positive = acceptation of a malicious user False negative = refusal of a legitimate user Connaissance : si un attaquant acquiert cette preuve et l’utilise, l’utilisateur légitime ne peut prouver son innocence ou qu’il n’a pas divulgué son mot de passe.

IV- Authentication Other types of Proof for entity authentication
Specific behaviour: Time between keystrokes on a keyboard Eye movements when looking at some patterns Use of supplementary information Example : use of localization information to give access only from a specific terminal Use of GPS (Global Positioning System) Combined proofs: Smartcard and PIN code Connaissance : si un attaquant acquiert cette prueve et l’utilise, l’utilisateur légitime ne peut prouver son innocence ou qu’il n’a pas divulgué son mot de passe.

IV- Authentication Strength of entity authentication
Weak authentication: Fixed passwords The prover proves its identity by giving its secret to the verifier One time password A new password is used at each authentication Strong authentication: Challenge-response protocols The prover proves its identity by showing to the verifier that it knows the secret without revealing it (thanks to a response to a fresh challenge sent by the verifier) An encryption using the secret may reveal some information on the secret Zero-knowledge protocols The prover shows that it knows the secret without revealing any information about it

IV- Authentication Fixed password authentication Threats and countermeasures
Password guessing: Exhaustive search (brute force): tries every possible string of symbols of a given length Dictionnary search: search through a restricted space of strings (words) Countermeasures: Set a password and change default passwords! Don’t use trivial passwords Increase the length of passwords (possibly limited on some systems) Increase complexity of passwords (use a larger set of symbols) Use a password verifier (computation of entropy, password cracker) Randomly generate passwords Force the renewal of passwords (with reuse control) Limit authentication trials (block the 3 account after 3 failures) Informer user (last successful authentication, failures) Compromis entre complexité du mot de passe et capacités humaines : un mot de passe trop long ou complexes sera écrit sur un bout de papier

Password spoofing Assumption: no mutual authentication The attacker impersonate the verifier Example : the attacker has installed a program that mimics a login screen; if user tries to connect, the program records the login / password, write an error message, stops its execution Countermeasures Indicate the number of authentication failures Use a trusted path: ensures that the user is communicating with the OS (Windows command CTRL+ALT+DEL) Mutual authentication : the user also authenticates the system Other attacks Intercept the password on the network (password sniffing) Installation of a keylogger (software or hardware) Phishing (= Phreaking + fishing) Phishing = Phreaking + fishing Phreaking ) phone freak, piratage des systèmes téléphniques Attaques reposant sur l’ingénierie sociale et consistant à faire croire à la victime qu’elle s’adresse à un tiers de confiance. Les navigateurs web mettent certaines informations dans des caches, par exple pour que les utilisateurs peuvent revenir sur des pages déjà visitées. Pour avoir accès à un compte en ligne il faut rentrer un mot de passe sur une page web. Sin onferme l’application de la banque sans fermer le navigateur, un nouvel utilisateur peut revenir sur la page avec le mot de passe.

Compromise of the password file Verifier must store the passwords in a file The attacker observes or modifies the content of the password file Countermeasures Cryptographic protection: One-way function (crypt(3) in Unix) Salting: the password is stored with a supplementary information, the salt Access control: only authorized users can access to the password file Write-protection: otherwise the attacker just has to modify a password No read protection (Unix : /etc/passwd) A combination of both previous countermeasures Shadow password files in HP-UX (/.secure/etc:passwd) Use of a proprietary format to protect write access (Windows NT, security through obfuscation) Crypt(3) = répète 25 fois une version modifiée de l’algorithme DES, utilisant un bloc ne contenant que des 0 comme valeur de départ et le mot de passe comme clef Attaque par dictionnaire : caculer f(x) pour tous les x Le sel ralentit l’attaque par dictionnaire car il n’est plus possible de rechercher les mots de passe de plusieurs utilisateurs simultanément

IV- Authentication Fixed password authentication Single-sign-on
Several passwords may be requested: To connect to a station To access to the network To access to a server To access to a database … Single-Sign-On (SSO) User enters his password only once The system stores the password, and takes in charge the future authentication The system must know the password! Trade-off between ease of use / security

IV- Fonctions de sécurité 1
IV- Fonctions de sécurité 1. Identification et authentification Authentification par mot de passe : mots de passe à usage unique (1/2) Mots de passe à usage unique : vers l’authentification forte Protège contre les interceptions de mots de passe Basé sur une liste pré-partagée, sur un incrément ou sur une fonction à sens unique Exemple protocole de Lamport (schéma utilisé dans S/Key) a veut s’identifier à b a possède un secret w, et h fonction à sens unique connue par a et b t : constante définissant le nombre d’authentification autorisées on définit par récurrence : h0(w)=w, hi(w)=hi-1(h(w)) pour 1it i-ième mot de passe : wi=ht-i(w) a transfère à b par un canal sûr w0=ht(w), b initialise son compteur compt_a à 1 à la i-ème identification : a calcule wi (event calculé auparavant) et envoie à b M1, a  b : a,i, wi b vérifie que compt_a =i et que h(wi)= wi-1 (exple si t=100, après 100 authentifications a génère un nouveau secret w)

A doit générer un nouveau secret …
IV- Fonctions de sécurité 1. Identification et authentification Authentification par mot de passe : mots de passe à usage unique (2/2) a secret : w fonction de hachage : h nb d’authentification : 3 b fonction de hachage : h nb d’authentification : 3 compteur pour a : compt_a Canal sûr w0 Initialisation calcule w0 =h3(w) stocke w0 compt_a := 1 A,1, w1 vérifie que compt_a= 1 vérifie que w0=h(w1) stocke w1, compt_a := 2 Authentification 1 calcule w1 =h2(w) vérifie que compt_a= 2 vérifie que w1= h(w2) stocke w2, compt_a := 3 A,2, w2 Authentification 2 calcule w2 = h (w) A,3, w3 vérifie que compt_a= 3 vérifie que w2= h (w3) compt_a := 0 Authentification 3 utilise w3 = w A doit générer un nouveau secret …

IV- Fonctions de sécurité 1. Identification et authentification Authentification par défi-réponse Principe : le prouveur prouve son identité au vérificateur en lui démontrant qu’il possède un secret sans révéler ce secret grâce à une réponse à un défi variant dans le temps Défi : utilisation de nonce garantissant une notion de fraîcheur/unicité Nombre pseudo-aléatoire nécessite un message supplémentaire pour envoyer le défi Numéro de séquence nécessite de mémoriser les numéros de séquence déjà utilisés Estampille (horodateur, « time stamp ») + horloges synchronisées (noté t) les horloges doivent être sécurisées ! Combinaison de nonces : nombre aléatoire concaténé à un numéro de séquence ou à une estampille permet de garantir qu’un nombre aléatoire n’a pas été dupliqué

IV- Fonctions de sécurité 1. Identification et authentification Authentification par défi-réponse Authentification forte par défi réponse: critères de classification Système cryptographique à clefs publiques ou à clefs secrètes Nombre de messages: 2 passes, 3 passes ... Authentification unilatérale (one-way) ou mutuelle (two-way) Avec ou sans utilisation d’une tierce-partie de confiance (TPC) Authentification directe : a et b s’authentifient directement l’un avec l’autre Authentification arbitrée : une TPC participe dans les échanges du protocole Avantage : a et b n’ont pas besoin de secret pré-établi Inconvénients : la disponibilité de la TPC est critique et la TPC peut surveiller toute l’activité d’authentification

IV- Fonctions de sécurité 1. Identification et authentification Authentification par défi-réponse Types de protocoles par défi-réponse Protocoles d’authentification forte par défi-réponse Utilisant une clef symétrique Basé sur un chiffrement à clef publique Basé sur la vérification d’une signature A apport de connaissance nul

IV- Fonctions de sécurité 1. Identification et authentification Authentification par défi-réponse Protocole de distribution de clef (Key establishment protocol) Protocole permettant de distribuer une clef symétrique entre deux parties (ou plus) Protocole de transport de clef (Key transport) : la clef est générée par une des parties puis distribuer à l’autre partie Protocole de mise en accord sur une clef (Key agreement): les deux parties participent à la génération de la clef (exemple : Diffie Hellman) Protocole de distribution de clef authentifiée distribuer un secret entre deux parties dont les identités ont été vérifiées Cette clef (symétrique) est souvent appelée clef de session Permet de limiter la quantité de données chiffrées avec une même clef Permet de rendre indépendants des sessions de communications différentes Une clef de session est aussi appelée secret à court terme, par opposition aux secrets à long terme (les clefs symétriques ou privées utilisées pour l’authentification)

IV- Fonctions de sécurité 1. Identification et authentification Authentification par défi-réponse Conventions de notations Kab : clef secrète partagée entre a et b (utilisée avec un algorithme symétrique) PKa : clef publique de a (utilisée avec un algorithme asymétrique) SKa : clef privée de a (utilisée avec un algorithme asymétrique) CERTa : certificat de a (émis par une autorité de certification connue) Si m désigne un message {m}Kab (resp. {m}PKa et {m}SKa) : m chiffré avec Kab (resp. PKa et SKa) Sa(m) : signature de m par a h(m) : MDC (« message detection code ») calculé sur m avec la fonction de hachage h hK (m) : MAC (« message authentication code ») calculé sur m avec la fonction de hachage paramétrée par la clef secrète K, hK

IV- Fonctions de sécurité 1. Identification et authentification Authentification par défi-réponse Langage de description d’un protocole cryptographique Protocole :=Message : Message Message := (Mk , Entité  Entité : Data) Commentaire Entité := a | b | s | x/a | x/b | x/s (a alice, b bob, s serveur, x attaquant) Data:= a | b | s | x (identifiants) CERTi | (certificats resp. de l’entité i) K | K {Ksa,Ksb ,Kab,PKa,PKb,PKs,SKa,SKb,SKs} ni | m (nonce généré par l’entité i et numéro de séquence) ti | ri (estampille et nb aléatoire généré par l’entité i) Data.Data | (concaténation, “.” parfois remplcé par “,”) {Data}K (donnée chiffrée avec K) Si(Data) (donnée signée par l’entité i) Data* (donnée optionnelle)

IV- Fonctions de sécurité 1. Identification et authentification Authentification par défi-réponse Protocoles avec chiffrement symétrique Supposent l’existence d’une clef secrète pré-partagée K Le prouveur démontre sa connaissance de K en chiffrant un défi (et éventuellement des données) Authentification mutuelle à deux passes avec nombre aléatoire M1: b  a : rb M2: a  b : { ra . rb . b }Kab M3: b  a : {rb . ra}Kab Une clef de session peut être dérivée à partir de ra Protocole de transport de clef

IV- Fonctions de sécurité 1. Identification et authentification Authentification par défi-réponse Protocoles basés sur un chiffrement avec une clef publique Le prouveur déchiffre avec sa clef privée un challenge chiffré avec sa clef publique Exemple : Needham Schroeder à clefs publiques (NSPK, 78) M1: a  s : a . b M2: s  a : {PKb . b}SKs M3: a  b : {ra . a}PKb M4: b  s : b . a M5: s  b : {PKa . a}SKs M6: b  a : {ra . rb}PKa M7: a  b : {rb}PKb Une clef de session peut être dérivée à partir de ra et rb Protocole de mise en accord sur une clef

IV- Fonctions de sécurité 1. Identification et authentification Authentification par défi-réponse Protocoles basés sur une signature Le prouveur signe un challenge Vérification d’un certificat Exemple : Protocoles ITU-T X509 authentification mutuelle avec transport de clef optionnel k1 et k2 : clefs de session ra et rb : nombres aléatoires incluant un numéro de séquence Protocole X509 à 3 passes avec nombres aléatoires : M1: a  b : CERTa . da . Sa( da ) avec da= ra . b . data1* . {k1 }PKb* M2: b  a : CERTb . db . Sb( db ) avec db= rb . a . ra . data2* . {k2 }PKa* M3: a  b : rb . b . Sa( rb,b ) Autre exemple : protocoles ISO [ISO/IEC9798part3] Authentification mutuelle X509 à 2 passes avec estampille

IV- Fonctions de sécurité 1. Identification et authentification Authentification par défi-réponse Protocoles à apport nul de connaissance (1) Le prouveur démontre la connaissance d’un secret sans révéler d’information sur ce secret Pour cela le prouveur montre qu’il connaît la solution d’un problème sans révéler la solution Exemple intuitif : avoir la clef de la porte de la cave A B C D

IV- Fonctions de sécurité 1. Identification et authentification Authentification par défi-réponse Protocoles à apport nul de connaissances (2) Le prouveur P et le vérificateur V se tiennent à l’entrée de la cave A Engagement : P pénètre jusqu’au point de rencontre B et choisit au hasard un accès à la porte BC ou BD Défi : V pénètre en B, choisit un chemin (BC ou BD) et demande à P de s’y rendre en empruntant ce chemin Réponse : P répond en franchissant au besoin la porte avec la clef Contrôle : V vérifie que P apparaît bien en B Le protocole est itéré n fois

IV- Fonctions de sécurité 1. Identification et authentification Authentification par défi-réponse Protocoles à apport nul de connaissance (3) Principe de la cave Si un tricheur T rentre à la place de P, il a une une chance sur deux de bien répondre À la n-ième itération il a 1/2n de se faire passer pour P P prouve qu’il possède la clef, mais V ne peut jamais savoir si la porte a été ouverte : aucune connaissance sur la clef n’est dévoilée Exemples de protocoles Protocole de Fiat et Shamir Protocole de Guillou et Quisquater Protocole de Schnorr

IV- Fonctions de sécurité 1. Identification et authentification Authentification par défi-réponse Simulation : V essaie produire une vidéo montrant P en train de s ’identifier, mais sans interagir avec P (le rôle de P est joué par qqn ne connaissant pas le secret) Bob installe une caméra à l’entrée de la cave A Elle permet de connaître l’ensemble des informations échangées entre P et V V avance au point B et lance son défi Par exemple la caméra filme le lancer d’une pièce de monnaie Si P revient par le mauvais couloir, V efface l’enregistrement Il est nécessaire de faire 2n essais pour obtenir n expériences réussies

IV- Fonctions de sécurité 1. Identification et authentification Authentification par défi-réponse Indistinguabilité Une personne extérieure visionnant la bande vidéo est incapable dire s’il s’agit d’une vraie preuve ou d’une vidéo Apport nul de connaissance Cette vidéo ne contient pas d’information sur le secret Donc le visionnage d’une véritable interaction ne révèle aucune information sur le secret

Exemple protocole de fiat Shamir Problème
Soit n=p×q avec p et q premiers, et x<n, alors il est très difficile de calculer une racine carrée de x Equivalent au problème de factorisation en nombre premier Initialisation P choisit p et q deux grands nombres premiers (n=p×q) P choisit un nombre aléatoire s premier avec n (1≤s≤n-1) et calcule v=s2 mod n P envoie (v,n) à V (la clef publique de de P est (v,n), la clef privée est s) Principe : P va prouver qu’il connaît une racine carrée de v

x e y Exemple protocole de fiat Shamir P : n, s V : n, v = s2 mod n
génère r calcule x =r2 mod n x e tire au sort e dans{0,1} calcule y = r × se mod n y vérifie que y2 = x × ve mod n

Exemple protocole de fiat Shamir Propriété de complétude
Si P connaît s, alors il peut répondre aux différents défi Propriété de correction Si P ne connaît pas s, il peut générer un y, et Pour un e fixé envoyer x = y2 × v-e mod n V pourra détecter avec une probabilité ½ que P ne connaît pas s Après k itérations V détectera la fraude avec une probabilité de 1 – 1/2k Propriété « Zero-knowledge » On peut construire un simulateur qui construit des triplets (x,0,y) ou (x,1,y)

IV- Fonctions de sécurité 1. Identification et authentification Autres types d’authentification Protocole d’authentification de l’origine de messages Utilisation d’un algorithme asymétrique de signature M1, a  b : a,m,Sa(m) m désigne un message Utilisation d’un MDC, et d’une clef secrète M1, a  b : a,m,{h(m)}kab Utilisation d’un MAC M1, a  b : a,m, hkab(m) Protocoles d’authentification de transaction Authentification de l’origine + unicité Ajout de paramètre de temps pour assurer la faîcheur

IV- Fonctions de sécurité 1. Identification et authentification Résumé
Types d’authentification Mécanismes utilisés Authentification de l’origine de message une signature un MDC un MAC Authentification d’entité Faible par mot de passe un mot de passe fixe un mot de passe à usage unique Forte par défi-réponse un chiffrement symétrique une fonction à sens unique un chiffrement asymétrique A apport de connaissance nul une preuve de connaissance

IV- Fonctions de sécurité 1. Identification et authentification Attaques sur les protocoles de défi-réponse Modèle de l’attaquant (modèle de Dolev Yao) X peut écouter les messages échangés ; X peut bloquer les messages ; X peut rediriger les messages ; X peut enregistrer les messages ; X peut rejouer les messages ; X peut fabriquer (chiffrer et déchiffrer) de nouveaux messages à partir d’anciens X ne sait pas déchiffrer (sans avoir la clef) dans le temps d’une session (par contre une clef d’une session précédente peut être cassée) Convention X/A  B : M signifie que X envoie le message M à B en se faisant passer pour A A  X/B : M signifie que X intercepte le message M envoyé par A à B, B ne le recevant pas

IV- Fonctions de sécurité 1. Identification et authentification Attaques sur les protocoles de défi-réponse Attaque de type “man-in-the-middle” un attaquant peut intercepter les messages entre A et B, et se fait passer pour l’une des parties auprès de l’autre exemple de protocole vulnérable : Diffie-Hellman Parades échanger des valeurs publiques authentifiées (voir protocole EKE) authentifier les valeurs publiques après l'échange (voir IKE)

IV- Fonctions de sécurité 1. Identification et authentification Attaques sur les protocoles de défi-réponse Attaque sur la fraîcheur S’appuie sur le rejeu de message X a enregistré un message (ou une partie) d’une ancienne exécution X rejoue ce message dans l’exécution courante Exemple: attaque de Denning Sacco sur NSSK (voir transparents suivants) Solution : utiliser une estampille, ou un numéro de transaction Estampille : suppose que les horloges sont bien synchronisées Beaucoup de protocoles de la littérature ne sont pas vraiment protégés contre le rejeu (Otway-Rees, …)

IV- Fonctions de sécurité 1. Identification et authentification Attaques sur les protocoles de défi-réponse Attaque sur la fraîcheur (2) Exemple : protocole de Needham-Schroeder à clefs symétriques (NSSK) [NS78] M1, a  s : a.b. ra M2, s  a : {ra . b . Kab . {Kab . a}Ksb }Ksa M3, a  b : {Kab . a}Ksb M4, b  a : {rb}Kab M5, a  b : {rb - 1}Kab Attaque de Denning-Sacco : l’attaquant x a enregistré une session précédente et a pu “casser” oldKab M3’, x/a  b : {oldKab . a}Ksb (x rejoue un vieux message) M4, b  x/a : {rb}oldKab (x connaît oldKab) M5’, x/a  b : {rb - 1}oldKab (b pense partager une clef secrète “fraîche” oldKab avec a) x peut communiquer avec b en se faisant passer pour a !

IV- Fonctions de sécurité 1. Identification et authentification Attaques sur les protocoles de défi-réponse Attaque sur la fraîcheur (3) Parade : utiliser une estampille comme protection contre le rejeu M1: a  s : a.b M2: s  a : {b . Kab . ta . {Kab . a . ta}Ksb }Ksa (le nombre aléatoire disparaît) M3: a  b : {Kab . a . ta}Ksb (b vérifie la validité de M3 avec ta, plus besoin de M4 et M5)

IV- Fonctions de sécurité 1. Identification et authentification Attaques sur les protocoles de défi-réponse Attaques par réflexion Protocole d’authentification à chiffrement symétrique M1: a  b : ra M2: b  a : {ra,rb}Kab M3: a  b : rb Attaque : M1: a  x/b : ra M’1: x/b  a : ra M’2: a  x/b : {ra,r’a}Kab M2 :x/b  a : {ra,r’a}Kab M3: a  x/b : r’a Parade : éviter la symétrie dans les messages M2: b  a : {b,ra,rb}Kab

IV- Fonctions de sécurité 1. Identification et authentification Attaques sur les protocoles de défi-réponse Attaque par confusion de type Au niveau abstrait : un msg est une séquence de champs : (id, valeur d’un nonce, ...) Au niveau concret : un msg est une suite de bits qui est interprétée en un msg abstrait Principe : l’attaquant se débrouille pour que le récepteur accepte une suite de bits comme valide, mais avec une interprétation différente de celle initialement voulue par le créateur. Parade : ajouter des “tags” (format TLV) à l’implémentation

Exercice: M3 B-> C/S: M.A.B. {NA. M.A.B}KAS.{NB.M.A.B}KBS
IV- Fonctions de sécurité 1. Identification et authentification Attaques sur les protocoles de défi-réponse Attaque par confusion de type (2) Exemple: protocole de Otway-Rees M1: a  b : m . a . b . {ra . m . a . b}Ksa m identifiant de transaction M2: b  s : m . a . b . {ra . m . a . b}Ksa . {rb . m . a . b}Ksb M3: s  b : m . {ra . Kab}Ksa . {rb . Kab}Ksb M4: b  a : m . {ra . Kab}Ksa Supposons que m fait 32 bits, a et b 16 bits, et Kab 64 bits, Attaque : il suffit que c rejoue la partie chiffrée de M1 M1: a  x/b : m . a . b . {ra . m . a . b}Ksa M4: x/b  a : m . {ra . m . a . b}Ksa Conclusion : a accepte m . a . b comme nouvelle clef (envoyée en clair) ! Exercice: trouver une attaque où x se fait passer pour s auprès de b. Exercice: M3 B-> C/S: M.A.B. {NA. M.A.B}KAS.{NB.M.A.B}KBS M4 C/S->B: M.{NA.M.A.B}KAS.{NB,M,A,B}KBS M5 B->A: M, {NA, M,A,B}KAS

IV- Fonctions de sécurité 1. Identification et authentification Attaques sur les protocoles de défi-réponse Attaques en multi-sessions Principe: plusieurs sessions étant éxécutées, éventuellement en parallèle, des messages d’une session sont utilisés pour former des messages d’une autre session Exemple: Attaque avec entrelacement de sessions et oracle (M6’, M7’) M3’: a  x : {ra . a}PKx M3”: x/a  b : {ra . a}PKb M6”: b  x/a : {ra . rb}PKa M6’: x  a : {ra . rb}PKa M7’: a  x : {rb}PKx M7”: x/a  b : {rb}PKb Rappel : NSPK original (les clefs sont déjà connues) M3: a  b : {ra . a}PKb M6: b  a : {ra . rb}Pka M7: a  b : {rb}PKb a pense que seuls a et x connaissent ra et rb b pense que seuls a et b connaissent ra et rb Correction : M6: b  a : {ra . rb . b}PKa

IV- Fonctions de sécurité 1. Identification et authentification Attaques sur les protocoles de défi-réponse « Binding attack » l’attaquant arrive à lier sa clef publique à l’identité d’un autre agent Attaque par encapsulation l’attaquant arrive à faire chiffrer par un autre agent une donnée qu’il a choisie Attaques dépendantes de l’implémentation confusion de type: présence ou absence de tags implémentation des nonces: aléatoires/ prévisibles Interactions avec méthode de chiffrement chiffrements bit à bit vs. chiffrements par blocs: M4: b  a : {nb}Kab M5: a  b : {nb - 1}Kab si le mode de chiffrement est bit à bit, et nb impair il suffit de modifier le dernier bit.

IV- Fonctions de sécurité 1. Identification et authentification Validation des protocoles de défi-réponse Principes de conception [AN94] et [AN95] Principe 1 : chaque message doit clairement dire ce qu’il signifie (i.e. son interprétation doit uniquement dépendre de son contenu). Principe 2 : les conditions dans lesquels les messages sont joués doivent être clairement stipulées. Principe 3 : mentionner explicitement le nom d’un agent si c’est nécessaire pour la compréhension du message. ... Ces principes permettent d’éliminer beaucoup de failles, mais Attaques plus subtiles: besoin d’une approche systématique (outillable) pour analyser un protocole. Approches formelles pour la vérification de protocoles cryptographiques Attaque par entrelacement de sessions sur Needham-Schroeder à clef publique détectée par model-checking par Lowe Exemple d’outil :

IV- Authentication Certificates and PKI Distribution of public key
Public File SKA Public publishing Ex : attach a PGP public key to an , or publish it on a webpage Use of a directory service: Ex.: Link the public key in Active Directory (Windows) The directory service must be trusted Certificate Exchange of public keys certified by a trusted third party (TTP) Direct exchange without the TTP participation PKB PKX A: PKA B: PKB C : PKC D: PKD E: PKE PKX {m}PKB {m}PKX B SKB Attacker X (PKX, SKX) Les algorithmes de chiffrement asymétrique sont basés sur le partage entre les différents utilisateurs d'une clé publique. Généralement le partage de cette clé se fait au travers d'un annuaire électronique ou bien d'un site web ou autre mode. Toutefois, avec ce type de distribution, l’utilisateur n’est pas sûr s’il s’agit bien de la clé publique de l’utilisateur qu’il veut contacter. Par exemple, un attaquant peut corrompre l’annuaire de telle manière que les clés publiques affichées vont être les siennes et peut ainsi déchiffrer tous les messages signés destinés à d’autres utilisateurs. D’où la notion de certificat. Problème plus général est comment gérer les authentifiants d’une manière distribuée/ réseau. B A PKA, CERT(A, PKA,) SKA SKB

IV- Authentication Certificates and PKI Certificate
A certificate links an identity to a public key (1978) A certificate certificat : <ID, Public Key, Validity, CA signature> Certification Authority (CA): trusted authority Certificate includes the CA signature: difficult to forge Signature generally based on RSA The public key of CA is largely known Certificate may be sent directly or stored in a public directory (not necessarily secured) Certificate format X.509 is the standard most in use internationally CA recense et contrôle l'utilisation des certificats. Elle possède une liste des certificats révoqués. Les certificats à la norme X.509 se distinguent des solutions de simple cryptographie comme OpenPGP par le fait qu'ils contiennent des champs d'information certifiés par des autorités de certification reconnues. Ces champs sont visibles en cliquant sur le petit cadenas d'un navigateur web.

IV- Authentication Certificates and PKI X509 standard
IUT X.509 standard Serial number Signature algorithm Name of the CA that issued the certificate Validity of the certificate Start date Expiration Date Owner of the certificate Information on the certificate owner’s public key Algorithm Public Key Signature of the CA Optional information (extensions) Informations complémentaires optionnelles.

IV- Authentication Certificates and PKI Certificat : types
Certificates signed by a local authority Certificates for internal usage Signed by a local server Security of communications inside an organization (ex: intranet) Certificates signed by a certification authority Security of communications with anonymous users or organisations Ex : secure website open to everybody

IV- Authentication Certificates and PKI Certificate management : PKI
Public Key Infrastructure (PKI): manage the certificate during their lifetime User registration Certificate generation Certificate publishing Certificate renewal Certificate revocation Revocation list publishing (CRL : “Certificate revocation list”) User identification and authentication Ensemble de composants physiques et logicielles et algorithmes qui délivre un ensemble de services pour ses utilisateurs

IV- Authentication Certificates and PKI PKI : components
Certification Authority (CA) Sign the certificate requests and the revocation lists Registration Authority (RA) Generate the certificate and checks the user identity Repository (R) Store the certificates and revocation lists End entity (EE : End Entity) User or system that owns the certificate EE = person  client certificate EE = Web server  server certificate EE = network device  VPN certificate RA 2. Validation of identity and public key 3. Entity authentification 4. Certificate EE CA 1. Key generation R

IV- Authentication Certificates and PKI Authority Hierarchy
Each CA owns a certificate issued by its parent The certificate of the root CA0 is self-signed CA0 Certification path CA1 CA2 CA3 CA4 CA5 Certificate of Website validated by A Website A B C Certificate of A validated by C Certificate of C validated by B

Introduction to Information System Security

Présentations similaires

Présentation au sujet: "Introduction to Information System Security"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Introduction to Information System Security

Présentations similaires

Présentation au sujet: "Introduction to Information System Security"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back