Sécurité des RO Partie 5 : S-MIME, PGP, Sbox, OTP...

Protocoles Protocoles

d'authentification d'authentification

& &

d'autorisationd'autorisation

Anas ABOU EL KALAMAnas ABOU EL KALAM

[email protected]@enseeiht.fr

Sécurité des RO

Partie 5

2 Anas Abou El Kalam

Rappel: Utilités la sécurité à tous les niveaux

Liaison physique : Bluetooth

Transport : SSL, TLS

Liaison : CHAP, PAP

Réseau : authentification IP (IPsec)

Session : SHTTP

Présentation

Application : S-MIME, PGP, Sbox, OTP

Boîtier de chiffrement

SSL, TLS, SHTTP

SSH

IpSec


Plan

� Protocoles de baseProtocoles de base

– Authentification par pwd

– Défi-réponse

– S-key & OTP

� ApplicationsApplications

– PAP

– CJAP

– RAS NT

– LanMan

– CIFS

– NTLM

– Authentification HTTP

� KERBEROSKERBEROS

� SECURITY BOXSECURITY BOX

� LegislationLegislation4

Anas Abou El Kalam

Authentification = identification + vérification

� IdentificationIdentification = = présentation de l'présentation de l'identitéidentité : information non secrète, différente pour chaque : information non secrète, différente pour chaque utilisateur (nom, numéro, ...) connue (au moins) de l'utilisateur et du système informatique utilisateur (nom, numéro, ...) connue (au moins) de l'utilisateur et du système informatique

� Vérification de l'identitéVérification de l'identité = = l'utilisateur doit présenter quelque chose :l'utilisateur doit présenter quelque chose :

– qu'il connaît (mot de passe, ;)

– qu'il possède (badge, carte à puce, ;)

– qui lui est propre : biométrie (empreinte digitale, iris, voix, ;)

ou une combinaison : carte à puce + empreinte digitale

� La qualité des systèmes d'authentification dépend :La qualité des systèmes d'authentification dépend :du taux d'acceptation à tort (du taux d'acceptation à tort (false acceptation rate, FARfalse acceptation rate, FAR))et du taux de rejet à tort (false rejection rate, FRR).et du taux de rejet à tort (false rejection rate, FRR).Ex : empreinte digitale : Ex : empreinte digitale : FAR ≈ 10FAR ≈ 10-6-6 FRR ≈ 1/1.000 (Compaq, NEC) FRR ≈ 1/1.000 (Compaq, NEC) iris : typiquement : iris : typiquement : FAR ≈ 10FAR ≈ 10-12-12 FRR ≈ 1/10.000 (Sensar, IriScan) FRR ≈ 1/10.000 (Sensar, IriScan)

� Trois techniques, selon ce que connaît l'authentificateurTrois techniques, selon ce que connaît l'authentificateur– Secret partagé

– Secret, caractéristique de l'utilisateur (non-rejouable, non-falsifiable)

– Valeur publique vérifiant un secret maintenu par l'utilisateur (zero-knowledge)


Authentification à distance (secret partagé)

� Danger : écoute sur le réseau -> rejeuDanger : écoute sur le réseau -> rejeu

� Parades :Parades :Vérification locale (m-d-p crypté transmis par un serveur)

Protocoles à défi-réponse : m-d-p "une fois", S-Key , grenouille, carte à puce, ;

STATION DE

TRAVAIL

STATION DE

TRAVAIL

SERVEURS

ESPION


Exemple de défi-réponse

1.1. L’utilisateur tape son nom (U) et son mot de passe (Ku) sur la L’utilisateur tape son nom (U) et son mot de passe (Ku) sur la station.station.

2.2. La station transmet l’identité de l’utilisateur au serveur.La station transmet l’identité de l’utilisateur au serveur.

3.3. Le serveur recherche le mot de passe de l’utilisateur et chiffre un Le serveur recherche le mot de passe de l’utilisateur et chiffre un nombre aléatoire (défi) avec ce mot de passe.nombre aléatoire (défi) avec ce mot de passe.

4.4. La station prouve que le mot de passe est correct en déchiffrant le La station prouve que le mot de passe est correct en déchiffrant le défi et en le renvoyant après incrémentation et chiffrement.défi et en le renvoyant après incrémentation et chiffrement.

Danger : mots de passe stockés en clair sur le serveurDanger : mots de passe stockés en clair sur le serveur

STATION DE

TRAVAIL

Serveur

U, Ku

� �

U�

{aléa}Ku

¦ {aléa+1}Ku

U ’ Ku


S-Key : Quoi ?

�

��

�

�� ! ! � "# $ �% & � %! � '� % (! � # �! � # � $ ' $! ( #) � ! � # '� � � #) $ " # � *� $!+

�

,- �� ! $ � � � �! �. � � # % ( � % # �% # $/ $ ') � � � # % % - �% � # � $ ' $! ( . % � (01 � ( % $ � (�

2 . �) ) $! ! ) . � �3 #) � ! # $ �� ! �� ! ! � � % � & �) ) � �� ' ! ( "# �) . � �3 # )�- �� # ! 4 � % ) � � � % �� ! �� ( � # $% � " # � '! � % '� �� ! ! � ! # $& ) �+�

5 6 �� 7�� 6 � 8 � � 9 � : �� 9; � � � �6 <= � � � � 6 �� >� 8 � �? �6 � � � � 9@ A � B �� =C = �

�

�� 9 � 7 7�6 � � � � � D 7E � 9 � � � � 9 � �C �� @ � ��

F �@ �� G

�

�) % �4 $! �% � ��) �

�

# � H�) � $ * $. � $�)


S-Key : 1ère phase : enregistrement

U, secret

Serveur

U, aléa, cptr,

mdpcptr

U

mdp100

aléa, 100

mdp0 = H (aléa|secret)mdp1 = H (mdp0)

;

mdp100 = H (mdp99)

Commande keyinit


S-Key : 2ème phase : authentification

U, secret

U, aléa, cptr,

mdpcptr

Serveur

U

X

aléa, cptr-1

?mdpcptr = H (X)

Si oui : cptr = cptr-1

enregistrer mdpcptr = X

mdp0 = H (aléa|secret)mdp1 = H (mdp0)

;

X = H (mdpcptr-2)


One-Time Password (2)

� L’utilisateur dispose sur son compte de :L’utilisateur dispose sur son compte de :– un générateur de mot de passe, qui génère une série de mots de

passe aléatoires à partir d’une phrase secrète

=> une phrase secrète, c’est long à casser, mais facile à retenir;– SecureCard, implémentation logicielle (S-Key de Bellcore)

� Le serveur dispose d’une base de données dans Le serveur dispose d’une base de données dans laquelle il note :laquelle il note :– le login de l’utilisateur

– le dernier mot de passe utilisé avec succès

– un sel (= un nombre qui fait pour “perturber”)

– l’identifiant de l’algorithme à utiliser

– un numéro de séquence N


Serveur sécurisé

Pour chaque

utilisateur :

- dernier mot de passe

- n° séquence N

- ID algo.

- sel

Utilisateur

Phrase

secrète

Sel

Algo.

MdP(N)


N, sel, ID algo.

Sel

Algorithme

de hash

N-1 fois

1 foisMdP(N-1)

MdP(N)

Noter le MdP(N-1)

Décrémenter N 12 Anas Abou El Kalam


� Avantages :Avantages :– l’utilisation du sel permet à l’utilisateur d’utiliser la même

phrase secrète sur plusieurs machines– la phrase secrète ne circule nulle part

� Problème :Problème :– N est décrémenté à chaque connexion, au bout d’un

moment, N va être trop petit !• réinitialiser le compte : convenir d’un changement de mot de

passe, ou d’un changement de sel• ou interdire son utilisation


S-Key : Exemple d’authentification

�telnet nom_de_la_machine � ��

�

��

Response !" #$ %& '() $ ) $ $ *& # +) , #) '-

�

,) ./ *0 1) 1& ' !) 2 " $ $ ) 3 # *4 3) " 3 ( " 5 ' 5 3 ' * , *$ 5 2 & 3( %& 3 $ * !) # ' *6 *) ( -

�

7) , 3 *8 9 * # :) $ ' 2 , 3 $ ;& #-

�

<& 3 $ !) %() = 2 " $ $ ) ( " 3 .> * 0 1) ) ' " * #$ * !) $ 3 * ') - 14 Anas Abou El Kalam

Authentification "zéro-knowledge"

� Caverne d'Ali Baba (Guillou-Quisquater)Caverne d'Ali Baba (Guillou-Quisquater)

� A chaque essai, quelqu’un qui ne connaît pas le secret a une chance sur 2A chaque essai, quelqu’un qui ne connaît pas le secret a une chance sur 2

� L’authentificateur est convaincu, mais il ne peut transmettre sa convictionL’authentificateur est convaincu, mais il ne peut transmettre sa conviction

A B


Exemple : Fiat-ShamirSoit Soit nn un produit de deux grands nombres premiers, connu de tous les composants C du système. un produit de deux grands nombres premiers, connu de tous les composants C du système.

Chaque composant C Chaque composant C

� génère aléatoirement une valeur rc (1≤rc≤n-1), qu'il garde secrète,

� Calcule xc = rc2 mod n et publie xc

(Rabin a prouvé qu’il est aussi difficile de calculer rc connaissant xc que de factoriser n).

Supposons que B veuille authentifier A (≈ vérifier avec une confiance > 1-2Supposons que B veuille authentifier A (≈ vérifier avec une confiance > 1-2-t-t que A connaît que A connaît rraa). ).

� A génère tableau de t valeurs aléatoires vi (1≤vi≤n-1), en calcule les carrés modulo n (vi2 mod n) qu'il

envoie à B.

� B calcule une chaîne aléatoire de t bits bi qu'il transmet à A.

Pour chaque Pour chaque ii, A renvoie à B :, A renvoie à B :� zi = vi si bi = 0

� zi = ra.vi mod n si bi = 1

B calcule B calcule zzii2 2 mod nmod n et vérifie que : et vérifie que :

� zi2 = vi

2 mod n si bi = 0

� zi2 = xa.vi

2 mod n si bi = 1

Un intrus A’ n'a qu'une chance sur 2Un intrus A’ n'a qu'une chance sur 2tt de deviner à l'avance les de deviner à l'avance les bbii pour choisir les pour choisir les zzii22 qui satisferont la demande qui satisferont la demande

de B :de B :� si bi = 0, A’ génère vi et calcule vi

2 mod n qu’il envoie à l’étape 1, puis vi en 2

� si bi = 1, A’ génère zi et calcule zi2/xa mod n qu’il envoie en 1, puis zi en 2


Plan



– Défi-réponse

– S-key & OTP


– PAP

– CJAP

– RAS NT

– LanMan

– CIFS

– NTLM




� LegislationLegislation


PAP

� PAP = Password Authentication ProtocolPAP = Password Authentication Protocol– protocole d’authentification de liaisons point-à-point

• liaisons point-à-point = liaison entre deux hôtes uniquement et qui n'est pas conçue pour être utilisée dans un réseau

– demande d’authentification côté client ou côté serveur

� FonctionnementFonctionnement– lorsque l’utilisateur veut se connecter à un serveur, il doit donner son

login + mot de passe– suivant les versions de PAP utilisées, login + mot de passe peuvent

transiter en clair ou non ;

AuthentifiantLoginAlgorithme

à sens unique

Mot de passe

Exemple d’authentification où login et mot de passe ne transitent pas en clair


Les risques de PAP

� Authentification faibleAuthentification faible– si transit en clair : il suffit d’écouter sur la ligne !

– aucun mécanisme anti-rejeu : on peut essayer plusieurs login + mots de passe, ou capter un login + mot de passe chiffré et le rejouer

Client

Authentifiant

Serveur

Espion

Plus tard …Authentifiant


L’authentification “forte”

� PrincipePrincipe– consiste à générer un défi aléatoire, qui change à chaque

connexion

– le défi change à chaque connexion : on ne pourra pas le réutiliser

=> Cela n’empêche pas complètement le rejeu

Client

Serveur

Mot de passe

Algorithme

à sens unique

Authentifiant

DéfiEspion

Succès

Nouveau défi

Authentifiant EchecPlus tard, à une

prochaine connexion 20 Anas Abou El Kalam

CHAP : Challenge Authentication Protocol�

��

�� !�

��

��

�� "� � � � � � � � ��# � � �

La clé ne transite jamais en clair sur le réseau.

Impossible d’ouvrir une nouvelle session en “rejouant”


Authentification RAS NT

� R.A.S = Remote Access ServiceR.A.S = Remote Access Service– service d’accès distant sur Microsoft ® Windows NT

• opérer comme si vous étiez connecté à un ordinateur physiquement relié au réseau: exécuter Gestionnaire utilisateurs, Gestionnaire serveurs, Observateur d'événements.

� Plusieurs méthodes d’authentification disponiblesPlusieurs méthodes d’authentification disponibles– MD5-CHAP “Accepter une authentification chiffrée”– MS-CHAP “Accepter une authentification Microsoft”– DES : compatibilité avec réseaux Lan Manager– PAP “Accepter une authentification en clair”– SPAP : authentification Shiva, chiffrée

Client RAS Serveur RAS

défi

Méthode choisie, défi chiffré


Mots de passe sous Windows NT (1)

� SAM (Security Accounts Manager)SAM (Security Accounts Manager)– droits requis pour y accéder

– fichier vérouillé

– stocke des hashs des mots de passe (et non les pwd en clair)

– 2005 : fonction de hachage utilisée pour les mots de passe est MD5

DES (16 caractères) hash MD4 (16 caractères)


Constitution des hashs sous NT (2)

« Hash » DES (16 caractères)

64 bits => 8 caractères

Mot de passe de l ’utilisateur (en clair) : 14 caractèresPaddé avec

des NULLs si

nécessaire

Magic

number

(64 bits)

DES

Moitié chiffrée

Magic

number

(64 bits)

DES

Moitié chiffrée

Mot de passe en majuscules

1ère moitié 2ème moitié

7 caractères => 56 bits 7 caractères => 56 bitsMD4

hash MD4 (16 caractères)


Risques et solutions (3)

� RisquesRisques– attaque du dictionnaire

– il suffit de générer des mots de passe de 7 caractères et de comparer leurs empreintes (pas besoin de 14 caractères)

– ensuite générer toutes les variations Maj/Min pour trouver l ’empreinte MD4

– MD4 n ’est plus considéré comme sûr...

� System Key Fix (SP3)System Key Fix (SP3)– les empreintes sont stockées chiffrées

– la clé de chiffrement est elle-même chiffrée par une « clé de boot » ou « clé système ». Cette dernière peut être :• générée aléatoirement et stockée dans base de registres (non recommandé)

• dérivée d ’un mot de passe demandé au boot de la machine

• ou stockée sur une disquette nécessaire au boot


Common Internet File System (4)

� Le protocole CIFSLe protocole CIFS– partage de fichiers (NFS à la Microsoft)– standard – support de connexions lentes– amélioration de SMB (Server Message Block), héritier des protocoles

LanMan, Dos LM, NTLM ;– authentification mutuelle client et serveur (empêche les attaques

« sandwich »)– support de la signature SMB (SP3)

� Format de messageFormat de message– entête : protocole (0xFF, ’SMB ’), commande, état, uid, tid ;– données : chemin d ’accès

Entête CIFS Données


Niveau de sécurité CIFS (5)

Deux niveaux de sécurité sont proposés :Deux niveaux de sécurité sont proposés :

� niveau partage : niveau partage : – l ’accès à un partage est contrôlé par un mot de passe.

– un seul mot de passe pour tous les utilisateurs

– Il suffit que l ’utilisateur connaisse ce mot de passe et le chemin d ’accès au partage pour obtenir l ’accès aux données

� niveau utilisateur :niveau utilisateur :– un mot de passe par utilisateur

– pour accéder à l ’arborescence, l ’utilisateur doit s ’authentifier (identifiant, mot de passe)

– amélioration de l ’ancien protocole SMB


Authentification CIFS (6)

� L’authentification se L’authentification se déroule en trois déroule en trois étapes :étapes :– négociation du « dialecte »

suivant les capacités du client et du serveur

– authentification de l ’utilisateur (si mode utilisateur)

– authentification auprès de l ’arborescence désignée

client serveur

SMB_COM_NEGOTIATE

SMB_SESSION_SETUP_ANDX

SMB_TREE_CONNECT_ANDX


Authentification CIFS (7)

� Authentification en clair :Authentification en clair :– le client envoie au serveur son mot de passe en clair (en

mode utilisateur, envoyer l ’identifiant en plus).

– Supporté par tous

� Authentification LanMan par défi :Authentification LanMan par défi :– le serveur envoie un défi.

– réalisation d ’un empreinte DES à partir du hash DES du mot de passe du client

– vérification du serveur

� Authentification NTLM par défi :Authentification NTLM par défi :– idem, mais utilisation du hash MD4 du mot de passe du

client et du hash DES.

– SP4 : LM-Fix permet d ’éviter d ’utiliser le hash DES du mot de passe


Authentification par défi LanMan (8)

Hash DES du mot de passe utilisateur \0

16 caractères 5 caractères

Bloc sur 21 caractères

7 caractères 7 caractères 7 caractères

Challenge

(8 caractères)DES


Envoyé au serveur

Idem ...

Découpage en 3


Authentification par défi NTLM (9)

Hash MD4 du mot de passe utilisateur \0

16 caractères 5 caractères

Bloc sur 21 caractères


Challenge

(8 caractères)DES


Envoyé au serveur

Découpage en 3


Résultat de l ’authentification LanMan

+ si V<SP4


Authentification HTTP (1)

� HTTP 1.1 prévoie des mécanismes HTTP 1.1 prévoie des mécanismes d�’authentification :d�’authentification :– entêtes WWW-Authentication et Authorization

– authentification basique : identifiant et mot de passe circulent en clair ! Déjà prévu dans HTTP 1.0 et hélas très courant sur Internet;

– authentification Digest (1999): on envoie un hash MD5 d ’un défi. Hélas, pas (encore) implémenté par les navigateurs et serveurs Web standards (RFC 2617)

– authentification NTLM : on utilise le hash DES et MD4 du mot de passe de l ’utilisateur pour chiffrer un défi envoyé par le serveur (cf authentification NTLM). Propriétaire et implémenté sur Internet Explorer et IIS.


Authentification HTTP : déroulement (2)

Client Serveur

GET

401 UnauthorizedWWW-Authenticate:NTLM

GET …Authorization:NTLM <base64

msg_init> 401 UnauthorizedWWW-Authenticate:NTLM

<base 64 msg_rep>

GET …Authorization:NTLM <base64

msg_end>

HTTP 1.1/ 200 OK


Authentification NTLM sur HTTP (3)

Protocole (« NTLMSSP\0)

Type (0x01) Réservé

Réservé

Taille du domaine

Offset domaine 0x00

Taille host

Offset host 0x00

host

domain





Réservé

Taille du message (0x28) Réservé

Réservé

Challenge (8 octets)

Réservé





Réservé

Taille réponse LanMan (0x18)

Offset réponse LanMan 0x00

Taille réponse NTLM (0x18)

Offset réponse NTLM 0x00

Taille domaine

Offset domaine (0x40) 0x00

Taille utilisateur

Offset utilisateur 0x00

Taille host

Offset host 0x00

0x00

Taille message 0x00

Réservé

Domaine

User

Host

Réponse LanMan

Réponse NTLM


Plan



– Défi-réponse

– S-key & OTP


– PAP

– CJAP

– RAS NT

– LanMan

– CIFS

– NTLM






Kerberos : plan

▷▷▷▷ Kerberos > Introduction : pourquoi Kerberos ?> Le protocole et les échanges> MIT Kerberos et les Applications> Attaques

▷▷▷▷ Déploiement> UNIX> Cisco (routeurs et switches)> Win2K

© 2001 Sécurité.Org 38 Anas Abou El Kalam

Kerberos

� ObjectifsObjectifs

– protocole d’authentificationd’authentification utilisé sur Unix

– gratuit,développé par le MIT

– supporté par S-HTTP• Utilise DES et des clés partagées• Tiers de confiance• utilise une horloge pour :

• limiter l’usage des clés dans le temps• détecter les attaques par rejeu• Authentification mutuelle

� RemarqueRemarque▷Kerberos ne fournit pas d’autorisation

▷ uniquement de l’authentificationl’authentification▷▷▷▷ Kerberos ne fait pas de chiffrement de données


Pourquoi utiliser Kerberos ?▷Authentification sécurisée

▷▷▷▷ Pas de transmission du mot de passe

▷▷▷▷ Single Sign On (regrouper tous les accès derrière un seul et unique mot de passe) n’est pas une bonne solution de sécurité

▷▷▷▷ Gestion centralisée de l’authentification

▷▷▷▷ Standard IETF (RFC 1510)


Kerberos (1)

– EntitésEntités

Client

Serveur de distribution de clé KDC

Service


Rôle du KDC (2)

� Le KDC se divise en deux parties :Le KDC se divise en deux parties :– le serveur d’authentificationserveur d’authentification (AS)

– le service de distribution de ticket d’accèsservice de distribution de ticket d’accès (TGS). • Un ticket est une information qui permet d’accéder à un service. Il est

valable pendant une durée limitée

� Serveur d’authentification :Serveur d’authentification :– conserve une base de données contenant les clients et des services

ainsi que leurs clés privées

– génère une clé de session (ticket) pour accéder au TGS

� Service de distribution de ticket :Service de distribution de ticket :– c’est un service “comme un autre”

– il est généralement sur la même machine que le serveur d’authentification (mais ce n’est pas requis)


Lexique Kerberos (1)

▷▷▷▷ KDC : Key Distribution Center. Base de données des clients et des serveurs (principaux) et les clés privées associées

▷▷▷▷ principal : trinôme <primary name, instance, realm> > user : login/staff@REALM > service : service/hote.fqdn@REALM

▷▷▷▷ primary : nom d’utilisateur ou du service

▷▷▷▷ instance : “qualifie” le primary (rôle/groupe)

▷▷▷▷ realm : domaine d’authentification

© 2001 Sécurité.Org


Lexique Kerberos (2)

▷▷▷▷ keytab : fichier contenant une ou plusieurs clés (pour des hôtes ou des services). Aussi connu sous SRVTAB.

▷▷▷▷ client : entité pouvant obtenir un ticket (utilisateur/hôte)

▷▷▷▷ service : host, ftp, krbtgt, pop, etc.

▷▷▷▷ ticket : crédits (identité d’un client pour un service particulier)

▷▷▷▷ TGT : ticket donné par l’AS. Permet au client d’obtenir d’autres tickets pour le même royaume


Key Distribution Center

▷▷▷▷ Responsable de la maintenance des clés maîtres et de la mise à disposition des tickets Kerberos

▷▷▷▷ L’Authentication Service (AS) donne au client une clé de session et unTicket Granting Ticket (TGT)

▷▷▷▷ Distribue les clés de session et les tickets pour les services via le Ticket Granting Service (TGS)



Le Protocole Kerberos (1)

▷▷▷▷ Ticket Kerberos


Domain

Principal Name

Ticket Flags

Encryption Key

Domain

Principal Name

Start Time

End Time

Host Address

Authorization Data

Chiffré


Kerberos (3)

Demande accès à TGSC,TGS

TGT “Ticket Granting ticket”

Kctgs + Nom de TGS chiffré par Kc

Kctgs + Nom de C + validité, chiffré par KTGS

KctgsClient Authentication Server

Connaît la clé secrète des clients et

des servicesConnaît Kc (sa clé secrète)

Ticket Granting Service (TGS)

Connaît sa clé secrète KTGS

Heure de C + Nom de S chiffré par Kctgs

Clé de session + Nom de C, chiffré par KTGS

Kctgs

Kcs + Nom de S chiffré par Kcs

Kcs+Nom de C+validité,

chiffré par Ks

Kcs

Kctgs = clé de session C-TGS

Kcs = clé de session C-S


Kerberos (4)

� AvantageAvantage– l’utilisateur n’entre son mot de passe qu’une seule fois,

lorsqu’il demande l’accès au TGS

� Problèmes de KerberosProblèmes de Kerberos– il faut “Kerberiser” les applications

– le serveur d’authentification doit être sûr

– si quelqu’un vole le mot de passe de l’utilisateur, il peut “tout” faire...


Kerberos (5) : exemple

% kinit

Password for [email protected]:

% klist

Ticket cache: /var/tmp/krb5cc_1234

Default principal: [email protected]

Valid starting Expires Service principal

24-Jul-95 12:58:02 24-Jul-95 20:58:15 krbtgt/[email protected]

L’utilisateur entre son mot de passe

Realm : domaine d’authentification

On obtient un premier ticket pour le service TGS (krbtgt)


Kerberos (6) : exemple

% rlogin newhost.domain

Last login: Fri Jul 21 12:04:40 from etc etc

% klist

Ticket cache: /var/tmp/krb5cc_1234

Default principal: [email protected]

Valid starting Expires Service principal

24-Jul-95 12:58:02 24-Jul-95 20:58:15 krbtgt/[email protected]

24-Jul-95 13:03:33 24-Jul-95 20:58:15 host/[email protected]

% kdestroy

% klist

klist: No credentials cache file found while setting cache flags

(ticket cache /var/tmp/krb5cc_1234)

L’acquisition du ticket pour newhost.domain est transparent

(effectué par le TGS). On peut manuellement effacer les tickets


t icket


▷▷▷▷ Echanges de tickets Kerberos

▷▷▷▷ Ports: kinit: 88/udp kpasswd (Unix): 749/tdp kpasswd (Win): 464/{tcp,udp}


Key Distribution Center

AuthenticationService

Ticket GrantingService

Utilisateur Service Réseau



▷▷▷▷ Obtention d’un Ticket Granting Ticket (1+2)

> (1) Demande d’un TGT

> (2) TGT (déchiffré avec le hash du mot de passe de l’utilisateur)


Client KDC

Demande de TGT (1)

TGT (2)



▷▷▷▷ Obtenir et utiliser un Service Ticket (3+4+5)

> (3) Demande de ST (avec le TGT) > (4) ST et clé de session > (5) ST pour l’authentification


Client

KDC

Serveur

Demande ST (3)

ST et SK (4)

ST (5)



▷▷▷▷ Délégation de l’authentification


Client

Serveur

Serveur

KDC

TGT + ST

Demande de ST

ST et SK

ST


Realms

▷▷▷▷ Un royaume est un domaine d’authentification > Une base de données Kerberos et un ensemble de KDCs

▷▷▷▷ Organisation hiérarchique (nouveauté dans la version 5)

▷▷▷▷ Authentification uni ou bi-directionnelle

▷▷▷▷ Authentification inter-realm > transitive > directe entre royaumes




▷▷▷▷ Authentification entre domaines


Client

Serveur

KDC

Demande de TGT

Demande de ST

ST et SK

KDC

TGT

ST et SK


Distribution du MIT

▷▷▷▷ Version utilisée: 5.1

▷▷▷▷ Inclus les logiciels client et serveur

▷▷▷▷ Plate-formes supportées : UNIXes (xBSD, Linux, Solaris, AIX, HP-UX, OSF/1, ...)MacOS 10

▷▷▷▷ DNS peut être utilisé



Applications Cerbèrisées

▷▷▷▷ telnet (avec chiffrement DES) et r-commandes

▷▷▷▷ CVS et ksu, klogin, k*

▷▷▷▷ SSH 1.2 supporte Kerberos V (utiliser au moins la version 1.2.30)

▷▷▷▷ SSL v3.0

▷▷▷▷ Cygnus Kerbnet (NT, MAC, Unix)

▷▷▷▷ non supporté par samba (problèmes liés aux extensions MS)


Cerbèrisation d’une application

▷▷▷▷ Toutes les applications sont adaptables

▷▷▷▷ Utilisation de l’API GSS

▷▷▷▷ Transport du ticket géré par l’application



Problèmes liés au NAT

▷▷▷▷ L’adresse du client se trouve dans le ticket

▷▷▷▷ Nécessité d’ajouter l’adresse translatée traduite dans le ticket

▷▷▷▷ Patch pour la version 5.1 (MIT Kerberos)


Attaques (1)

▷▷▷▷ Vulnérabilité dans le système d’authentification par usurpation (partie AS du KDC): fichier keytab et enregistrement des principaux pour le service (http://www.monkey.org/~dugsong/kdcspoof.tar.gz)

▷▷▷▷ Rejeu: détecté (synchronisation d’horloge du client et du serveur)

▷▷▷▷ Clés exposées: durée de vie limitée, mais utilisées pour plusieurs sessions

▷▷▷▷ Faille dans l’utilisation des fichiers temporaires : utiliser krb5-1.2.1+



Attaques (2)

▷▷▷▷ Recherche du mot de passe : utiliser une bonne passphrase

▷▷▷▷ Clients “chevaux de Troie” : OTP

▷▷▷▷ Relation de confiance implicite entre les royaumes

▷▷▷▷ Forwarding des tickets

▷▷▷▷ Autres: KDC, stations partagées, ...


Clients *NIX

▷▷▷▷ RedHat (6.2 and 7) supporte Kerberos V > Installer le patch RHSA-2001:025-14

▷▷▷▷ Solaris/OpenBSD ne fournissent qu’un support Kerberos IV



Kerberos V sur les clients *NIX (1)

▷▷▷▷ Authentification gérée par l’API Kerberos

▷▷▷▷ Configuration de l’authentification par utilisateur : ~/.k5login - liste les principaux qui peuvent

se connecter sur ce compte

~/.k5users - liste les commandes qui peuvent être lancées via ksu (similaire à sudo)

▷▷▷▷ alternative PAM non conseillée


Kerberos V sur les clients *NIX (2)

▷▷▷▷ Telnet cerbèrisé : disponible

▷▷▷▷ SSH cerbèrisé : > SSH de SSH.Com 1.2.x et 2.x supportent Kerberos V > OpenSSH (jusqu’a la version 2.5.1) ne supporte pas encore Kerberos V: http://www.sxw.org.uk/computing/patches/



Kerberos V et Cisco (1)

▷▷▷▷ Routeurs Cisco > Telnet cerbèrisé > Authentification par mot de passe utilisant Kerberos (telnet, SSH et la console)

> Une instance peut être associée à un privilège (configuré localement)

▷▷▷▷ Switches Cisco > Telnet uniquement (SSH disponible dans les 6.1 mais sans support pour Kerberos)



▷▷▷▷ IOS & mémoire sur les routeurs : > Nom de la fonctionnalité : Kerberos V client support > Feature set requis : au moins Enterprise

> N’est pas supporté par toute la gamme, par exemple :- Cisco 16xx- Cisco GSR (12xxx - Gigabit Switch Router)

> Besoins en mémoire :

Note: toujours vérifier via le Cisco IOS Feature Navigator


Hardware IOS RAM / Flash

26xx 12.0 32 / 8

12.1 48 / 16

72xx 12.0 64 / 16

12.1 64 / 16



▷▷▷▷ Exemple de configuration d’un routeur :aaa authentication login default krb5-telnet local

aaa authorization exec default krb5-instance

kerberos local-realm COLT.CH

kerberos srvtab entry host/[email protected] ...

kerberos server COLT.CH 192.168.0.14

kerberos instance map engineering 15

kerberos instance map support 3

kerberos credentials forward

line vty 0 4

ntp server 192.168.0.126



▷▷▷▷ CatOS & mémoire sur les switches : > Au moins Supervisor Engine Software Release 5.x

> Uniquement supporté par les Catalyst 4000, 5000 et 6K > Uniquement supporté par les SE I (pas par les SE II) sur Cat6K

> Besoins en mémoire :

Note: toujours vérifier les Release Notes


Hardware CatOs Mémoire

4000 5.2+ 64

6.1 64

6000 5.4+ 64

6.1 64 (SE1)



▷▷▷▷ Exemple de configuration d’un switch :#kerberos

set kerberos local-realm COLT.CH

set kerberos clients mandatory

set kerberos credentials forward

set kerberos server COLT.CH 192.168.0.82 88

set kerberos srvtab entry host/[email protected] ...

#authentication

set authentication login kerberos enable telnet primary

set authentication enable kerberos enable telnet primary

#ntp

set ntp client enable

set ntp server 192.168.0.11


Kerberos V et Win2K (1)

▷▷▷▷ Supporte Kerberos pour les connexions interactives

▷▷▷▷ Le protocole est un Security Provider sous le SPPI (Security Support Provider Interface) et est lié à la LSA (Local Security Authority)

▷▷▷▷ Le cache des tickets est géré par la LSA

▷▷▷▷ Telnetd supporte Kerberos



Kerberos V et Win2K (2)

▷▷▷▷ Support Tools

▷▷▷▷ Configuration d’une station Win2K: ksetup /setdomain COLT.CH ksetup /addkdc COLT.CH kdc.colt.ch ksetup /setmachpassword password ksetup /mapuser [email protected] localuser ksetup /mapuser * *

▷▷▷▷ Windows Time Server (+ registry)

▷▷▷▷ Pas de SSH cerbèrisé, seulement quelques (mauvais) clients telnet


Plan



– Défi-réponse

– S-key & OTP


– PAP

– CJAP

– RAS NT

– LanMan

– CIFS

– NTLM






� Généralités– développé par MSI S.A

– sécuriser les communications sur Internet

– SHL n’est pas un protocole. Il est construit “au dessus” de HTTP

� Mécanismes– scellement HMAC-MD5...

– chiffrement Triple D.E.S EDE 112 bits par défaut, ou D.E.S 40 bits

– échange des clés de session par R.S.A 1024 bits, certificats X509

– chiffrement et scellement sélectifs.

– authentification par mot de passe, par carte à puce, par secret RSA

Security BOX ® SHL


Security BOX ® SHL (2)

� Présentation générale de la solutionPrésentation générale de la solution– sur le poste client : un proxy HTTP

– sur le serveur : une gateway, et derrière, les différents sites WEB à protéger.


Security BOX ® SHL (3)

Proxy SHL Gateway SHL

1N° de version

Rep-1

Mécanismes de chiffrement et de scellement supportés, certificat et logo du site, aléa (anti-rejeu), défi

pour authentification

2

Choix des mécanismes, aléa, réponse au défi

d’authentification, clés de session chiffrées par clé publique

du site, scellement 1 & 2

Vérification

Agent d’authentification

Défi

Génération de clés de session

(scellement, chiffrement)

Rép.

Rep-2

Confirmation de l’authentification, scellement

Rep-1 & Rep-2

Conf.

Rép.Fournisseur d

’authentification

Défi

Conf.

Vérif.


Security BOX ® Classic (1)

� GénéralitésGénéralités– développé par MSI S.A

– sécurisation “locale” des fichiers

– une version freeware et une version “classic” (quelques légères différences)

– plateformes Windows, Mac, UNIX (Linux, Solaris, AIX...)

– très simple d’utilisation (drag & drop)



� Fonctions :Fonctions :– chiffrement par du Triple D.E.S

168 bits ou 56 bits

– gestion de listes de fichiers à chiffrer/déchiffrer

– gestion du mot de passe (demander à chaque chiffrement, toutes les 5 minutes;)

– création d’auto-extractibles (distribution plus facile)

– multi-utilisateurs : comptes séparés, possibilité de partage de fichiers

– procédure de sauvetage

– effacement sécurisé



Diversifiant

Mot de passe (mdp)

Fichier

Kf chiffré par Km

Fichier chiffré

par Kf

Génération aléatoire

d’une clé Kf

Création d’un compte :l’utilisateur choisit :- un diversifiant

- un mot de passe (mdp)

Clé maître (Km)

Algo.

Compte de l’utilisateur :

Km chiffré par mdp

Chiffrement

d’un fichier :


La législation française

� La DCSSI (ex SCSSI)La DCSSI (ex SCSSI)– http://www.scssi.gouv.fr

� Décret du 17 mars 1999Décret du 17 mars 1999– http://www.internet.gouv.fr/francais/textesref/cryptodecret99200.htm– Libres d ’utilisation, fourniture, importation, exportation :

• protection de logiciel, protection d ’identifiants• signatures, authentification et vérifications• systèmes de contrôles d ’accès physiques (DAB;), gestion de

facturation

=> à condition qu’ils ne puissent pas être déviés en méthodes de chiffrement

– Libres d ’utilisation et d ’importation :• chiffrement jusqu ’à 40 bits• chiffrement jusqu ’à 128 bits à condition que le fournisseur l’ait déclaré,

ou qu’ils soient réservés à un usage strictement privé.

� Projet de Loi sur la Sécurité Quotidienne Projet de Loi sur la Sécurité Quotidienne (oct 2001)(oct 2001)

– Enrichi de 13 amendements pour la lutte contre le terrorisme


Références

� RFC 1938 “A One-Time Password System” de RFC 1938 “A One-Time Password System” de N. Haller et C. Metz N. Haller et C. Metz

� KerberosKerberos– RFC 1510 “The Kerberos Network Authentication Service (V5)”

de C. Neuman et J. Kohl• http://www-bib.fh-bielefeld.de/epub/doc/rfc-index.html

– The Moron’s Guide to Kerberos http://www.isi.edu/gost/brian/security/kerberos.html

� S-HTTP : Adam Shostack’s home pageS-HTTP : Adam Shostack’s home page– http://www.homeport.org/~adam/

� SSL v3.0, TLS v1.0SSL v3.0, TLS v1.0– http://home.netscape.com/eng/ssl3/ssl-toc.html– RFC 2246 : http://www.ietf.org/rfc/rfc2246.txt?number=2246

� Security BOX ® SHL, Security BOX ® Classic Security BOX ® SHL, Security BOX ® Classic – http://www.msi-sa.fr

Sécurité des RO Partie 5 : S-MIME, PGP, Sbox, OTP...

Documents

Transcript of Sécurité des RO Partie 5 : S-MIME, PGP, Sbox, OTP...