Mes ramblings du travail

SHA-2

jean-yves poublan — Sun, 01 Feb 2009 09:38:32 GMT

En cryptographie, la fonction de hachage (ou calcul de condensé) est essentielle. Une de ses applications est la génération de signatures selon le schéma hash and sign, et bien sûr leur vérification, ou encore le calcul de codes d'authentification de messages (MAC). La fonction de hachage est à sens unique, mais surtout, elle doit être résistante aux collisions. Vous trouverez des informations didacticielles et pas trop indigestes (pun intended J) sur le sujet chez Mironov.

On a assez longtemps utilisé MD5 (Message Digest - 128 bits) qui aujourd'hui (et même depuis plusieurs années – 1996?) est à bannir définitivement (voir http://blogs.technet.com/pascals/archive/2008/12/31/collisions-md5-et-vrais-faux-certificats.aspx). Son successeur, SHA-1 (Secure Hash Algorithm - 160 bits) est aussi suspecté d'être sujet à collisions et déjà considéré comme un peu short pour la signature électronique. Selon NIST (National Institute of Standards and Technology) : "Federal agencies should stop using SHA-1 for digital signatures, digital time stamping and other applications that require collision resistance as soon as practical" (voir aussi http://www.rsa.com/rsalabs/node.asp?id=2834 ou encore RFC 4270).

Les collisions permettent en théorie de forger une signature, ou plutôt de créer un deuxième document (appelons-le « faux » document) pour lequel la signature générée sur un premier document (« vrai » document) est valide car les deux documents produisent le même condensé. L'attaque dite de « seconde pré-image » qui consiste à trouver un faux document, qui plus est « utile », pour un premier document imposé est bien plus difficile que l'attaque de collision de base (paradoxe des anniversaires), pour laquelle l'attaquant peut choisir les deux documents, avant de faire signer le vrai document par la victime. Un certificat étant un document signé suite à une requête de certification, on conçoit comment il est possible de créer de faux certificats par une attaque de collision.

L'attaque de collision MD5 aujourd'hui praticable sur les seuls certificats MD5 s'apparente à une attaque pour laquelle l'attaquant choisit le vrai et le faux document. Cependant, pas mal de contraintes subsistent pour l'attaquant : la structure de la partie du certificat à faire signer par la CA est imposée, et seule une partie de son contenu est relativement libre. De plus, il est nécessaire pour l'attaquant de prédire les numéros de série et date de validité qui seront affectés au vrai certificat par l'autorité de certification (on peut raisonnablement penser qu'on retrouvera ce type de contraintes dans beaucoup d'attaques de collision car il faut que la victime accepte de son plein gré de signer le vrai document). A noter aussi que le faux certificat doit comporter les bits nécessaires à la collision, ce qui constitue une véritable « verrue » à dissimuler et qui pourrait éventuellement mettre la puce à l'oreille de l'utilisateur (très bien averti), et du moins être détectée lors d'une investigation.

Il faut évidemment arrêter de générer des certificats MD5, et dans l'idéal, il faut arrêter de les utiliser et de leur accorder confiance. Plus facile à dire qu'à faire dans certains cas mais guidelines et recommandations existent.

La publication FIPS 180-2 du NIST a standardisé dès 2002 les condensés dits SHA-2 de longueur 256, 384, et 512 bits (ces trois variantes sont dénommées SHA-256, SHA-384, et SHA-512). Seuls SHA-256 et SHA-512 sont réellement différents en ce sens que les calculs se font sur des entités 32 et 64 bits, ou encore des tailles de blocks 512 et 1024, respectivement, et SHA-384 n'est qu'une version de SHA-512 au résultat tronqué. SHA-2 fait maintenant partie de Suite-B, qui est le standard NSA spécifiant les suites d'algorithmes cryptographiques à utiliser pour la sécurité des systèmes d'information du gouvernement US. Dans la course contre les cryptanalystes, NIST ne perd pas de temps et a déjà lancé le concours pour « SHA-3 ».

Pour un développeur de fonctions de sécurité mettant en jeu la signature et les certificats, ou n'importe quel mécanisme de sécurité nécessitant la résistance aux collisions, l'adoption de SHA-2 est désormais un must, et il apporte en plus la conformité avec Suite-B. Mais comment choisir entre SHA-256 et SHA-512 ? En termes de sécurité, SHA-512 fournira en théorie plus de marge, si tant est qu'on en ait besoin. SHA-256 est censé fournir 128 bits de sécurité contre les attaques de collision, et SHA-512, 256 bits. Néanmoins, différentes applications ou protocoles présentent chacun leurs contraintes, et un niveau de sécurité de « seulement » 128 bits est pour l'instant réputé sûr pour beaucoup d'applications selon les préconisations de la DCSSI (voir aussi www.keylength.com).

La fonction de hachage est souvent utilisée conjointement avec du chiffrement. En termes de cohérence, on pourra utiliser SHA-256 avec AES 128 bits, et on préférera SHA-512 avec AES 256 bits. En termes de taille de messages pour le stockage ou la transmission, SHA-512 représente un coût fixe deux fois plus important que SHA-256, qui peut être impraticable pour un grand nombre de petits messages. Finalement, en termes de performance, SHA-512 est ciblé pour les systèmes 64 bits, et logiquement plus lent que SHA-256 sur les systèmes 32 bits (ce qui en principe n'est pas le cas sur un système 64 bits).

SHA-2 a été disponible de la part de Microsoft sur la plateforme Windows dès le .Net Framework 1.0 avec les classes en code managé, puis plus tard en code natif sur Windows Server 2003 SP1 avec CryptoAPI, et sur Windows Vista et Windows Server 2008 avec CNG (Crypto Next Generation) et CryptoAPI, et finalement sur Windows XP SP3 avec CryptoAPI.

Pour résumer :

API	Disponibilité de SHA2 au niveau de l'API
Classes .Net	A partir du .Net Framework 1.0: SHA256Managed, SHA384Managed, SHA512Managed A partir du .Net Framework 3.5 sur Windows Vista: SHA256Cng, SHA384Cng, SHA512Cng A partir du .Net Framework 3.5 sur Windows Server 2003 SP1, Windows Vista et Windows XP SP3: SHA256CryptoServiceProvider, SHA384CryptoServiceProvider, SHA512CryptoServiceProvider Le support de HMAC-SHA2 existe sur le .Net Framework en code managé depuis sa version 2.0 (HMACSHA256, HMACSHA384, HMACSHA512). A noter aussi le wrapper CNG du projet « CLR Security » : Security.Cryptography.HMACSHA256Cng, Security.Cryptography.HMACSHA384Cng, Security.Cryptography.HMACSHA512Cng. Signature RSA avec SHA-2 disponible récemment (.Net Framework 3.5 SP1) avec RSACryptoServiceProvider. Puisque la classe est un wrapper CryptoAPI, il faut en plus que la plateforme supporte SHA-2 au niveau CryptoAPI (et donc au minimum Windows Server 2003 SP1, Windows Vista, ou Windows XP SP3). On notera à ce sujet l'initiative http://www.codeplex.com/CryptoExtension. Signature ECDSA avec SHA-2 via ECDSACng à partir du .Net Framework 3.5 et Windows Vista. La signature DSA est limitée à SHA-1 (DSA 1024 - DSACryptoServiceProvider). La fonctionnalité n'a pas encore été « remontée » à la signature XML.
CNG	A partir de Windows Vista BCRYPT_SHA256_ALGORITHM ("SHA256"), BCRYPT_SHA384_ALGORITHM ("SHA384"), BCRYPT_SHA512_ALGORITHM("SHA512") Pour HMAC-SHA2, utiliser le flag BCRYPT_ALG_HANDLE_HMAC_FLAG lors de la connexion au provider d'algorithme. Signature RSA et ECDSA avec SHA-2. La signature DSA est limitée à SHA-1 (DSA 1024).
CryptoAPI	A partir de Windows Server 2003 SP1, ensuite Windows Vista, puis Windows XP SP3 AlgIDs CALG_SHA_256, CALG_SHA_384, CALG_SHA_512 Support via Microsoft Enhanced RSA and AES Cryptographic Provider, et Microsoft Base Smart Card Crypto Provider, si présent. Binaire rsaenh.dll. Pour HMAC-SHA2, utiliser CALG_HMAC, puis CryptSetHashParam: CryptCreateHash (CALG_HMAC) CryptSetHashParam (HMAC_INFO. HashAlgid = CALG_SHA_256) Signature RSA avec SHA-2. La signature DSA est limitée à SHA-1 (DSA 1024).

On ne répétera jamais assez aux développeurs d'éviter d'utiliser, lorsque possible, les primitives cryptographiques pour bâtir eux-mêmes les protocoles ou fonctions de plus haut niveau dont ils ont besoin. Les vulnérabilités se trouvent dans le protocole, ou l'application, rarement dans l'algorithme crypto en tant que primitive. Mironov cite pour exemple la construction naïve d'un MAC en tant que SHA(secret||message) plutôt que l'utilisation du standard HMAC-SHA (RFC 4868).

Que ce soit pour la génération d'une signature électronique, la dérivation d'une clé à partir d'un mot de passe, ou encore un code d'authentification, une utilisation naïve des primitives peut rapidement conduire au désastre, et on se reportera sur les APIs qui implémentent les méthodes standard, éprouvées, et approuvées par les agences de sécurité tels que HMAC-SHA, RSA, DSA, ECDSA, PBKDF2, etc.

A noter sur Windows 7 la nouvelle API CNG BCryptDeriveKeyPBKDF2 pour la dérivation de clé à partir d'un mot de passe selon RFC 2898 (PKCS#5), qui peut être utilisée avec SHA-2 si on le souhaite. Néanmoins, il est couramment admis que SHA-1 est largement suffisant pour ce scenario.

Windows 7 apporte aussi une nouvelle API native supportant la signature XML RSA et ECDSA avec SHA-2 (API CryptXML… - cryptxml.dll).

Qu'en est-il de PKIX ?

CAPI2 (crypt32.dll) désigne l'API Windows qui met en œuvre le X.509 et le CMS/PKCS#7 (Cryptographic Message Syntax). A partir de Windows Vista et Windows Server 2008, CAPI2 a été capable de prendre en charge les certificats SHA-2 (accessoirement, CAPI2 a aussi été porté sur CNG pour la prise en charge des courbes elliptiques). Une application est donc à même de vérifier une chaîne de certificats X.509 RSA et ECC à base de SHA-2 avec les API CertGetCertificateChain et CertVerifyRevocation. De même, les services de certificats ADCS (Active Directory Certificate Services) de Windows Server 2008 supportent l'émission de certificats SHA-2 RSA et ECC. Finalement, SHA-2 est supporté pour CMS. A ce titre on notera le draft http://www.ietf.org/internet-drafts/draft-ietf-smime-sha2-11.txt sur l'utilisation de SHA-2 avec CMS qui est censé mettre à jour RFC 3370. La mise en œuvre de S/MIME par Office Outlook 2007 (et le contrôle Outlook Web Access d'Exchange 2007) en tire parti, mais pas Windows Mail, ni Windows Live Mail. A noter que SHA-2 est supporté pour la signature, mais la dérivation de la KEK (Key Encryption Key) pour le chiffrement suite à l'accord ECDH utilise encore SHA-1 (dhSinglePass-stdDH-sha1kdf-scheme – voir RFC 3278). Windows 7 apporte le support de dhSinglePass-stdDH-sha256kdf-scheme et dhSinglePass-stdDH-sha384kdf-scheme selon RFC 5008 (comme évoqué plus haut, je ne pense pas que SHA-2 soit totalement indispensable pour la dérivation).

Sur Windows Server 2003 SP1 et SP2, le correctif 938397 APPLICATIONS THAT USE THE CRYPTOGRAPHY API CANNOT VALIDATE AN X.509 CERTIFICATE IN WINDOWS SERVER 2003 (http://support.microsoft.com/kb/938397) amène le support de SHA-2 au niveau CAPI2 de façon à pouvoir vérifier une chaîne comprenant des certificats RSA à base de SHA-2. Cependant Certificate Services de Windows Server 2003 ne peut pas générer de certificats SHA-2, et SHA-2 n'est pas disponible pour CMS.

Sur Windows XP, c'est le SP3 qui amène le support de SHA-2 pour CAPI2, et donc la possibilité de d'utiliser des certificats RSA avec SHA-2, avec IE7 par exemple. Comme pour Windows Server 2003, SHA-2 n'est pas disponible pour CMS.

Le tableau suivant synthétise le support de SHA-2 sur la plateforme:

	Windows XP	Windows Server 2003	Windows Vista	Windows Server 2008
CryptoAPI	SP3	SP1	RTM	RTM
CNG	--	--	RTM	RTM
Validation de certificats avec CAPI2	SP3	SP1 ou SP2 + KB938397	RTM	RTM
CMS avec CAPI2	Non	Non	RTM	RTM
Emission de certificats avec Certificate Services	--	Non	--	Oui - ADCS

Alors bon SHA-2, et merci à Philippe Beraud qui m'a transmis certaines de ces informations…

Windows Vista SP1 : de nouveaux PRNGs

jean-yves poublan — Mon, 07 Jan 2008 01:22:16 GMT

Le Service Pack 1 pour Windows Vista, ainsi que Windows Server 2008 sont bien là, au détour de virage de la nouvelle année. Une rapide recherche des nouveautés n'arrête pas de cracher « Adds an Elliptical Curve Cryptography (ECC) pseudo-random number generator (PRNG) to the list of available PRNGs in Windows Vista ». Cette information, quoiqu'exacte, mérite quelques précisions.

Le PRNG en question correspond au mécanisme DUAL_EC_DRBG à base de courbes elliptiques de la publication NIST SP 800-90 qui répond aux exigences de certaines entités gouvernementales. Cependant, DUAL_EC_DRBG est en quelque sorte sujet à controverse. Il est accessible pour les applications via l'API CNG (Crypt Next Generation) et le provider d'algorithme « DUALECRNG » (constante BCRYPT_RNG_DUAL_EC_ALGORITHM). DUAL_EC_DRBG n'est pas l'algorithme de génération de nombre aléatoire par défaut de la plateforme. Même s'il est possible de configurer CNG pour qu'il le soit, une telle configuration n'affecte que les applications CNG (note : cependant, de plus en plus d'applications et protocoles, aussi bien en mode noyau qu'en mode utilisateur, utilisent CNG).

Plus intéressant, l'algorithme PRNG par défaut de la plateforme est nouveau. Il s'agit du mécanisme CTR_DRBG (« Counter » Deterministic Random Bit Generation toujours de la publication NIST SP 800-90) qui met en jeu l'algorithme de chiffrement par blocs AES-256. CTR_DRBG concerne aussi bien les applications CNG en mode noyau ou utilisateur, que les applications CryptoAPI (via les CSP Microsoft). Le livre blanc du SP1 de Windows Vista a été mis à jour pour refléter cet état de choses.

Un troisième algorithme est disponible, il s'agit de l'algorithme dit « FIPS 186-2 » conforme à l'annexe 3.1 du standard DSS (FIPS 186-2) et à base de SHA-1 pour le calcul de la fonction G. FIPS 186-2 est exposé par CNG via le provider d'algorithme BCRYPT_RNG_FIPS186_DSA_ALGORITHM, et par CryptoAPI via les CSP de Microsoft de type DSS (CryptGenRandom prend en paramètre le handle du CSP). Cet algorithme est utilisé pour la génération de nombres aléatoires nécessaires à la signature électronique DSA. Je ne suis pas sur qu'une application en ait directement besoin, mais le provider d'algorithme DSA pour CNG (BCRYPT_DSA_ALGORITHM), et les CSP de type DSS en dependent.

Avec le SP1 de Windows Vista et sur Windows Server 2008, on a donc trois algorithmes PRNG :

Algorithme	Standard	Commentaire
CTR_DRBG	NIST SP 800-90	PRNG par défaut de la plateforme. PRNG des CSP MS de type RSA et disponible via CNG (BCRYPT_RNG_ALGORITHM).
DUAL_EC_DRBG	NIST SP 800-90	Disponible via CNG seulement (BCRYPT_RNG_DUAL_EC_ALGORITHM).
FIPS 186-2	FIPS 186-2	PRNG des CSP MS de type DSS et du provider d'algorithme BCRYPT_DSA_ALGORITHM pour CNG et disponible via CNG (BCRYPT_RNG_FIPS186_DSA_ALGORITHM).

La source d'entropie des PRNG a aussi été enrichie par le Trusted Platform Module (fonction TPM_GetRandom) lorsque disponible.

Sur Windows Vista RTM et Windows Server 2003 SP2, le PRNG par défaut (CSP MS de type RSA, FIPS.SYS sur Windows Server 2003, ou pour Windows Vista CNG, le provider d'algorithme BCRYPT_RNG_ALGORITHM) suit les recommandations de la section « General Purpose Random Number Generation » toujours de la publication FIPS 186-2 et aussi à base de SHA-1 pour la fonction G. Alors que le PRNG FIPS 186-2 assure que le nombre aléatoire généré est inférieur au nombre premier q de la clé publique DSA, cette variante générique, elle ne procède pas à cette réduction. La motivation pour son remplacement par CTR_DRBG de NIST 800-90 est de bénéficier des avancées les plus récentes en matière de standards cryptographiques.

Récemment, la presse s'est fait écho de défauts du PRNG de Windows 2000 et Windows XP mis en exergue par les informaticiens Dorrendorf/Gutterman/Pinkas de l'Université Hébraïque de Jérusalem et l'Université d'Haïfa. En principe, la conformité du PRNG de Windows Vista RTM et Windows Server 2003 SP2 à FIPS 186-2 fait que ces défauts n'affectent pas ces plateformes. De même, ils seront corrigés dans le Service Pack 3 de Windows XP par une conformité plus stricte au standard FIPS 186-2.

Finalement, il est bien connu qu'on peut utiliser l'API RtlGenRandom pour faire l'économie du « chargement » de CryptoAPI et un CSP (CryptAcquireContext). De même, les librairies c-runtime récentes de Microsoft utilisent RtlGenRandom pour la fonction rand_s. Il faut noter cependant que RtlGenRandom, même s'il utilise la même source d'entropie, n'implémente pas FIPS 186-2. D'ailleurs le commentaire de la documentation n'en recommande pas l'usage : «It (RtlGenRandom) may be altered or unavailable in subsequent versions. Instead, use the CryptGenRandom function. ». Pour avoir du FIPS 186-2 il faut utiliser CryptoAPI ou CNG, et on peut s'attendre à ce que sur Windows Vista SP1 et Windows Server 2008 ce soit la même chose pour CTR_DRBG.

S4U2Self et WCF

jean-yves poublan — Sat, 21 Apr 2007 09:27:25 GMT

Lors de mon précédent poste sur S4U2Self, j'ai un peu utilisé les termes impersonation et délégation sans y attacher plus de précision. J'ai aussi indiqué que ce sont les applications qui doivent mettre en œuvre la transition de protocole. En fait WCF (Windows Communication Foundation – précédemment Indigo), qui fait partie du .Net Framework 3.0 et qui est disponible aussi bien sur Windows Vista/Longhorn Server que sur Windows XP/Windows Server 2003, offre la transition de protocole d'une authentification client par certificat vers Kerberos.

Mais commençons par l'impersonation et la délégation. Sur la plateforme Windows, il est courant de faire la distinction entre une impersonation qui permet l'accès à des ressources locales, et une délégation qui permet l'accès à des ressources distantes. L'API Windows reflète cette distinction par le biais du niveau d'impersonation du jeton: SecurityAnonymous, SecurityIdentification, SecurityImpersonation, et SecurityDelegation (voir SECURITY_IMPERSONATION_LEVEL sur http://msdn2.microsoft.com/en-us/library/aa489535.aspx). Je vous encourage à relire le classique Windows Programming Security (Chapitre 4 – Logon Sessions) ainsi que le Livre Wiki de Keith Brown (ainsi bien sur que le SDK Windows), mais pour moi ces distinctions sont des facilités techniques liées à NTLM/Kerberos. Très schématiquement: si le client s'est authentifié via NTLM, le niveau du jeton est SecurityImpersonation, et le serveur ne peut accéder pour le compte du client qu'aux ressources locales. Si le client s'est authentifié via Kerberos (et moyennant le fait que la délégation Kerberos soit mise en œuvre), le niveau du jeton est SecurityDelegation, et le serveur peut accéder pour le compte du client à des services distants.

Cette distinction entre impersonation et délégation ne peut être généralisée. Je m'explique: pour pouvoir accéder à des ressources ou des services distants en tant que son client, un serveur doit avoir des "network credentials" pour ce client. Cela peut être le mot de passe du client ou un ticket TGT Kerberos "forwardable". Imaginons que le serveur possède le mot de passe du client, il peut ouvrir une session de logon pour le client (LogonUser), puis impersonner ce client (ImpersonateLoggedUser) et accéder à des ressources distantes pour le compte du client. Le niveau d'impersonation du jeton n'est pourtant "que" SecurityImpersonation. C'est aussi le cas d'une session de logon obtenue via S4U2Self. La session de logon possède un ticket Kerberos "forwardable", donc des "network credentials", malgré le fait que le niveau du jeton ne soit que SecurityImpersonation, l'accès aux ressources distantes pour le compte du client est possible. Je dirais aussi que le niveau du jeton SecurityDelegation indique que l'utilisateur s'est authentifié via Kerberos, et qu'il n'y a pas eu de transition de protocole.

L'utilisation de l'impersonation et de la delegation par WCF fait l'objet d'une fiche technique http://msdn2.microsoft.com/en-us/library/ms730088.aspx. Deux méthodes sont possibles:

S4U-Based Impersonation – cette méthode couvre la transition de protocole d'une authentification client par certificat vers l'ouverture d'une session de logon Windows via S4USelf. WCF prend en charge cette transition pour l'application.

Cached Token Impersonation – cette méthode couvre les autres mécanismes. Typiquement authentification basic, authentification client SSL/TLS avec mapping du certificat sur compte AD, Kerberos avec ou sans délégation, etc…

La documentation détaille les niveaux d'impersonation du jeton Windows obtenu pour chacun des cas. Des collègues m'ont demandé si cette documentation était réellement correcte car elle indiquait un niveau "Impersonation" pour des cas où l'accès distant (scenario d'une délégation) est possible. En regard de ce que je mentionne ci-dessus, la doc est correcte. On peut admettre cependant qu'il aurait été pertinent d'indiquer, en plus du niveau d'impersonation, les cas pour lesquels l'accès distant est possible, plutôt que de laisser le développeur/architecte le déduire.

Extraits de la documentation:

Impersonation Level Obtained from UserName Credentials and Cached Token Impersonation

Allowed Impersonation Level	Service has SeImpersonatePrivilege	Service and client are capable of delegation	Cached token ImpersonationLevel
n/a	Yes	Yes	Delegation
n/a	Yes	No	Impersonation
n/a	No	n/a	Identification

Impersonation Level Obtained from S4U-based Impersonation

Service has SeTcbPrivilege	Service has SeImpersonatePrivilege	Service and client are capable of delegation	Cached token ImpersonationLevel
Yes	Yes	n/a	Impersonation
Yes	No	n/a	Identification
No	n/a	n/a	Identification

Jusqu'à présent, il fallait coder soi-même la transition de protocole dans une application de type passerelle. WCF l'offre de base. Le revers de la médaille est que la passerelle doit s'exécuter en TCB comme l'indique le tableau ci-dessus.

RMS et gestion des droits numériques en entreprise avec IT-EXPERT

jean-yves poublan — Sat, 14 Apr 2007 08:58:40 GMT

La protection de vos documents et gestion des droits numériques en entreprise? C'est possible, avec Rights Management Services qui existe depuis 2003, qui a fait ses preuves et qui est maintenant bien ancré dans la plateforme. Le serveur RMS est un ensemble de services Web qui prend en charge la gestion des licences, et l'API cliente RMS (en style Win32 ou en classes .Net avec le .Net Framework 3.0) permet d'incorporer les fonctions de protection dans les applications. Vous trouverez une overview RMS dans mon article paru ce mois-ci dans it-expert: http://www.it-expertise.com/Rubriques/Default.aspx?cat=3.

En plus du téléchargement du SDK RMS, vous trouverez des informations utiles dans nos présentations récentes des JMS 2006 et Techdays 2007. Cette année, mes collègues Philippe Béraud et Stéphane Saunier ont présenté les possibilités d'intégration de RMS avec les identités ADFS sur Windows Longhorn Server.

S4U2Self et renforcement des services

jean-yves poublan — Sun, 08 Apr 2007 11:23:00 GMT

Il existe une fonction de la plateforme Windows Server 2003 qui permet d'ouvrir une session de logon pour un compte du domaine sans mot de passe. Pas mal! De mes tests, ca marche aussi sur Windows Vista.

Cette fonction s'appuie sur S4U2Self (S4U-to-Self) de la famille d'extensions Kerberos Windows (S4U ou Service-for-User), et on la désigne couramment du terme "transition de protocole". En quoi l'ouverture d'une session de logon sans mot de passe est-elle une transition de protocole? En rien. C'est plutôt qu'elle va permettre la fameuse transition de protocole, qui doit être faite par une application. Une telle application, disons une passerelle, va authentifier l'utilisateur via un protocole (par exemple authentification client SSL/TLS) puis va ouvrir une session de logon pour cet utilisateur, ce qui va lui permettre d'accéder aux ressources distantes via Kerberos (plus précisément une autre extension Windows dite S4U2Proxy) pour le compte de l'utilisateur. La "transition" du premier protocole vers Kerberos, c'est l'application qui l'effectue, pas le système.

Cette transition pourrait être faite sans S4U2Self, mais dans ce cas elle nécessiterait que l'application connaisse les mots de passe des utilisateurs. Pour ce faire elle pourrait les obtenir via une authentification "basic", ou tout simplement en avoir une liste. La transition de protocole facilite donc la mise en œuvre de passerelles frontales qui permettent l'accès à des services ou ressources "backend" en Kerberos, sans que ces passerelles n'aient connaissance des mots de passe des utilisateurs. Le scenario cible est celui d'une organisation ayant déployé un domaine Active Directory avec Kerberos, et souhaitant permettre l'accès à des ressources en extranet avec une authentification client SSL/TLS par certificat.

Ouvrir une session de logon sans connaitre le mot de passe du compte? Heureusement (ou bien évidemment) certaines conditions d'appliquent:

Le compte du domaine (autrement dit l'identité) qui effectue l'opération doit être approuvé pour la transition de protocole. Plus précisément, il s'agit de la configuration suivante au niveau du compte: "Trust this user for delegation to specified services only" et "Use any authentication protocol". Si la passerelle s'exécute avec un compte utilisateur dédié du domaine, c'est ce compte auquel il faudra faire confiance pour la transition de protocole. Si la passerelle s'exécute avec un compte built-in (Network Service, ou Local System), l'approbation pour la transition de protocole sera attribuée au compte machine du domaine.
Le TGT Kerberos "forwardable" ainsi obtenu ne permet d'obtenir ensuite un ticket de service Kerberos (via S4U2Proxy cette fois) que pour les services qui figurent dans la liste A2D2 (Allowed-to-delegate-to). Chaque identité approuvée pour transition a sa propre liste de contraintes A2D2.
Le compte de l'utilisateur pour lequel l'ouverture de session de logon sans mot de passe s'effectue ne doit pas être un compte "sensitive and cannot be delegated". Les comptes Active Directory peuvent ainsi être configurés pour interdire leur impersonation.
Le code de la passerelle effectuant l'opération doit faire partie de la Trusted Computing Base, autrement dit avoir le privilège SeTcbPrivilege.

Dans ses articles sur la transition de protocole (http://msdn.microsoft.com/msdnmag/issues/03/04/SecurityBriefs/ et plus récemment http://msdn.microsoft.com/msdnmag/issues/07/01/SecurityBriefs/default.aspx?loc=fr – maintenant disponible en Français J) Keith Brown analyse le trade-off entre une passerelle qui connait les mots de passe de l'utilisateur et une passerelle s'appuyant sur la transition de protocole. Il semble que la transition de protocole l'emporte de par la contrainte de délégation (les services cible doivent figurer sur la liste A2D2) qui limiterait les dégâts en cas de compromission du service. Pour ma part, je pense qu'une analyse au cas par cas est nécessaire. Dans son article d'avril 2004, Keith Brown mentionne qu'en théorie, la transition de protocole peut permette l'accès aux ressources distantes alors que l'accès aux ressources locales n'est pas possible. Cela m'a pris un moment pour percuter sur cette remarque anodine qui mérite explication.

Que ce passe-t-il lors d'une transition de protocole?

L'application invoque LsaLogonUser pour ouvrir une session de logon sans connaitre le mot de passe de l'utilisateur. Le système contacte le contrôleur de domaine via S4U2Self pour obtenir un TGT Kerberos pour l'utilisateur. Le système crée une session de logon Windows à laquelle est rattaché le TGT Kerberos. L'application peut maintenant impersoner la session de logon Windows pour accéder à des ressources locales, ou tenter d'accéder à des ressources ou services distants. Lors de l'accès à une ressource distante, le système obtient un ticket de service Kerberos auprès du contrôleur de domaine via S4U2Proxy. Le ticket de service permet d'authentifier l'utilisateur sur la machine distante et d'accéder à la ressource.

Que se passe-il si l'identité de l'application (compte de machine ou d'utilisateur du domaine) n'est pas approuvée pour la transition de protocole?

Dans ce cas, le contrôleur de domaine, via S4U2Self, renvoi bien un TGT Kerberos, mais celui-ci n'est pas "forwardable". Le système (dans le cas où l'application fait partie du TCB) crée une session de logon de niveau impersonation à laquelle est rattaché le TGT Kerberos. Apres impersonation, l'accès aux ressources locales est possible. Cependant un accès aux ressources distantes n'est pas possible parce que le TGT n'étant pas forwardable l'obtention d'un ticket de service via S4U2Proxy échouerait (le système ne le tente même pas).

Que se passe-t-il si l'application ne fait pas partie du TCB?

Dans ce cas, le TGT Kerberos obtenu via S4U2Self est bien forwardable (l'identité est approuvée pour transition de protocole), mais la session de logon Windows est de niveau identity. L'accès aux ressources locales n'est pas possible (un jeton de niveau identity est utile pour déterminer les groupes de l'utilisateur, mais ne permet pas l'accès aux ressources auxquelles l'utilisateur aurait droit). Puisque le TGT Kerberos sous jacent est de niveau forwardable, rien n'empêche l'obtention d'un ticket de service via S4U2Proxy tout à fait valide pour un accès distant. Cependant, le système n'est pas censé supporter ce scenario, et la situation est intenable, et c'est la raison pour laquelle elle a été mentionnée "en théorie".

Le tableau suivant illustre la situation:

Compte de service		Jeton	Ticket Kerberos S4U2Self	Fonctionnel
TCB	Approuvé pour transition	Impersonation	Forwardable	Délégation* Accès distant
TCB	-	Impersonation	Non forwardable	Impersonation Accès local
-	Approuvé pour transition	Identity	Forwardable	Identity Découverte des groupes (autorisation)
-	-	Identity	Non forwardable	Identity Découverte des groupes (autorisation)

*Via S4U2Proxy – sujet aux contraintes A2D2 et le fait que le compte de l'utilisateur ne soit pas "sensitive and cannot be delegated"

On fera remarquer que la notion de TCB est une notion tout à fait locale. Si vous êtes TCB, vous êtes tout puissant sur la machine en local. Le contrôleur de domaine, cela lui fait une belle jambe que vous soyez TCB ou non. D'ailleurs il ne le sait même pas. La notion d'approbation pour transition est quant à elle une notion du domaine. En local, que votre identité soit ainsi privilégiée pour la transition au niveau du domaine n'a que peu d'importance. Tant que vous n'êtes pas TCB, vous ne pourrez impersoner l'utilisateur (entendu sans connaitre son mot passe) ni accéder pour son compte à ses ressources. Ses ressources locales cela s'entend.

Pour les ressources distantes le fait que le système local (de la passerelle) ne le permet pas non plus ne doit pas être considéré comme une mesure de sécurité quelconque. Ce qui nous amène à la remarque (que vous trouverez évidente) suivante: le trust pour délégation est une fonction extrêmement sensible puisque l'identité du domaine ainsi trustée va pouvoir accéder aux ressources des autres et pour le compte des autres sans connaitre leur mot de passe. Granted, cet accès est contraint aux seules ressources figurant sur la liste A2D2, mais quand même... Il est fortement recommandé dès lors qu'on utilise la transition de protocole de configurer les comptes administrateur (ainsi que ceux qui n'ont pas lieu d'accéder aux services de la passerelle) en "sensitive and cannot be delegated. Malheureusement, Windows Server 2003 ne le fait pas automatiquement.

Je veux pour exemple de la sensibilité de la transition de protocole le scenario suivant: vous avez une machine du domaine dont le compte machine a été trusté pour délégation avec dans la liste A2D2 un serveur de fichiers. Un utilisateur "standard" qui n'a aucun droit sur le serveur de fichier en question ouvre une session de logon interactive sur cette machine et tente d'accéder aux fichiers du serveur de fichiers avec un net use. Non seulement l'accès réussi, mais l'accès se fait avec le compte d'administrateur du domaine. Le redirecteur SMB fait du zèle, et c'est commode! Si ce n'était pas le scenario souhaité, il aurait fallu restreindre et configurer le compte administrateur du domaine en "sensitive and cannot be delegated".

Et le renforcement des services, alors, après cette (longue) explication?

La factorisation des parties sensibles d'une application ou d'un service nécessitant privilèges élevés fait partie des meilleures pratiques de sécurité. Keith Brown l'illustre en factorisant la transition de protocole dans un composant COM+ out-process. La passerelle peut ainsi s'exécuter sans privilège TCB, et la partie du code nécessitant ce privilège (le composant COM+) ne fait pas face au réseau.

Sur Windows Vista et Longhorn Server, on pourra tirer parti des mécanismes de renforcement des services pour une telle passerelle en tant que service Win32. Imaginons que le service s'exécute avec le compte built-in Network Service. Ce compte ne possède pas moins d'une dizaine de privilèges. Hors, parmi ces privilèges, seul celui d'impersoner (impersonation de la session de logon obtenue via la transition de protocole elle-même effectuée par le composant COM+). La première chose qu'on pourra effectuer est la configuration du service pour n'avoir que ce privilège.

Pour permettre l'accès au composant COM+, on pourrait être tenté de rajouter le compte Network Service dans les rôles COM+ définis. Cependant cela donnerait accès à la transition de protocole à l'ensemble du code qui s'exécute en tant que Network Service. Plutôt, on configurera le service pour avoir un SID de service (SIDType=unrestricted, voir https://blogs.technet.com/voy/archive/2007/03/22/per-service-sid.aspx) qu'on pourra utiliser pour contrôler finement l'accès aux ressources du service (le composant COM+ peut être vu comme une ressource sensible du service). On ne peut pas directement rajouter un SID de service dans les rôles COM+ avec le snapin mmc "Component Services" mais on peut utiliser l'indirection d'un groupe local (comme "ProtocolTransitionUsers" par exemple). Dans ce cas, on rajoute le SID de service dans le groupe local qui est lui positionne dans le rôle COM+. La syntaxe à utiliser avec les outils d'administration est "NT SERVICE\<service_name>".

Finalement ou pourra utiliser les règles de restriction réseau (Windows Service Hardening rules) pour restreindre la passerelle aux seules communications réseau dont elle a besoin. Les règles WSH sont mises en place durant l'installation du service, et ne peuvent pas être modifiées par la configuration du pare-feu intégré Windows. Ces règles sont "statiques" et effectives quelque soit la configuration du pare-feu, y compris sa désactivation par un administrateur. Ces règles ne peuvent que restreindre l'accès au réseau par votre service, et en aucun cas elles ne peuvent l'élargir (par rapport à une configuration du pare-feu existante).

Vous vous demandez peut-être pourquoi dans cet exemple je propose un SIDType="unrestricted", plutôt que "restricted", et quelles sont les différences. Un SIDType "unrestricted" permet d'avoir un SID de service qu'on pourra utiliser pour un contrôle et une protection fine des ressources du service. Un SIDType "restricted" fait que, en plus du SID de service, le service s'exécute avec jeton restreint en écriture (concept nouveau sur Windows Vista – voir http://blogs.technet.com/voy/). Un SIDType="restricted" permet, en plus de la protection des ressources du service, une meilleure protection du système contre une compromission éventuelle du service. En ce sens, l'exécution restreinte de votre service en écriture est une mesure de bonne citoyenneté. Malheureusement, cette mesure peut être onéreuse pour le développeur d'un service Win32, car vous devez maitriser précisément l'ensemble des ressources pour lesquelles votre service a besoin d'un accès en écriture. Lorsqu'on utilise des APIs cela n'est pas toujours facile à faire.

Alors, à vos transitions! Et bon renforcement…

Renforcement des services

jean-yves poublan — Sun, 01 Apr 2007 17:10:24 GMT

Windows Vista et "Longhorn Server" comportent un certain nombre de mécanismes permettant de renforcer la sécurité des services Win32, et par là celle de la plateforme. Tandis que le contrôle des comptes utilisateurs UAC applique le principe du moindre privilège aux applications et concerne les sessions de logon interactives, le renforcement des services ("service hardening" en anglais) s'intéresse au moindre privilège pour les services et consiste en l'isolation de ceux-ci en session TS 0 ainsi que la mise en œuvre de mécanismes dont il appartient au développeur de tirer parti: la réduction des privilèges, l'utilisation d'un SID de service pour la protection des ressources du service de manière granulaire, la restriction en écriture pour la protection du système, et les restrictions réseau. Ces mécanismes visent aussi à faciliter l'usage des comptes built-in de service (Local Service et Network Service).

J'ai eu l'occasion d'animer une session sur le renforcement des services aux Techdays 07 et les transparents sont en ligne pour téléchargement. Cette session à donné lieu a une série de postes en collaboration avec mon confrère Cyril Voisin (aka Voy). Vous y trouverez, je l'espère, la marche à suivre, en tant que développeur pour renforcer la sécurité de vos services Win32.

Et Dieu inventa UAC

jean-yves poublan — Mon, 26 Mar 2007 22:44:26 GMT

Ca fait longtemps que je voulais faire un petit billet sur UAC. Mi-janvier, je pensais (naïf) que tout avait été dit. Depuis, User Account Control continue à déchainer les passions. Les uns s'indignent, critiquent et crient au scandale ou à la mauvaise plaisanterie (voyez plutôt, Vista Security Model – A Big Joke? Ou Kaspersky s'interroge…). Microsoft explique, et rationalise. Ben non, UAC n'est pas une frontière de sécurité nous dit Mark, "Security Features vs Convenience" nous dit Jim. Et puis, on ne va quand même pas chipoter sur les couleurs du prompt…

UAC, pour moi (hey, c'est mon blog ici, j'ai le droit de parler pour moi, hein), c'est l'exécution des applications en moindre privilège par défaut. Trois cas se présentent: 1) vous n'êtes pas admin et n'avez aucun privilège particulier. Très bien vous continuez comme cela. 2) vous n'êtes pas admin, mais votre compte utilisateur a trop de privilèges. Et bien on vous enlève ceux qui sont en trop. Allez circulez, restez pas là bouche bée! 3) vous êtes admin? Tous nos respects. Mais ici, tout le monde est au même régime: utilisateur standard.

Oh la, oh la! Pas de panique. On sait très bien que certaines actions nécessitent privilèges d'admin. Deux cas se présentent: votre compte n'est pas admin et n'a pas les privilèges nécessaires, et bien il va vous falloir trouver un admin qui puisse venir saisir son mot de passe sur le prompt d'élévation. C'est le scénario "Over The Shoulder" (OTS). Votre compte est admin, vous devez alors accorder votre consentement pour l'exécution en mode élevé. C'est le scénario "Admin Approval Mode" (AAM).

Embêtant UAC? Ben oui, on est obligé de ralentir, avec tous ces prompts. C'est comme les chicanes aux entrées des agglomérations. Intéressant UAC? Absolument, ca fait des années qu'on parle de s'exécuter en non admin sur Windows. Aujourd'hui Windows Vista me l'offre et s'est supporté par PSS. Plus besoin de lire Margosis, et de tenter les gymnastiques à la DropMyRights.

Une sécurité à toute épreuve? Ben non. Ce n'est pas parce que vous roulez à 90 que vous n'aurez pas d'accident. Sous XP, une meilleure pratique était d'utiliser deux comptes. Un compte utilisateur pour son travail "normal", et un compte administrateur pour les taches d'administration. Cette pratique est tout autant recommandée sous Windows Vista, et UAC ne vise nullement à la rendre inutile.

Accro de la vitesse? Ne supporte pas les prompts? Y'a pas d'OS à protéger sur cette machine? Pas de problème, vous pouvez désactiver UAC, et rouler à donf. Vous prenez vos responsabilités. C'est la première chose qu'a fait Barbara, ma belle maman.

Pour le développeur d'applications Windows Vista, y'a moins le choix. Si vous voulez obtenir le logo Vista (ou plutôt si vous voulez éviter d'indiquer dans les conditions requises "Vista sans UAC"), vous devez prendre en compte UAC et votre application, y compris son installation, doit se comporter décemment lorsqu'UAC est activé. UAC comporte aussi toute une série de paramètres de configuration. La virtualisation des ressources fichiers et base de registre peut être active ou non, la signature des applications nécessitant élévation obligatoire ou non, etc… Votre application se comportera-t-elle correctement dans tous ces cas de figure?

J'ai eu l'occasion de présenter une session UAC pour les développeurs aux Techdays 07 dans laquelle j'aborde ce que doit savoir un développeur pour franchir le cap UAC dans les meilleures conditions météo. Les slides sont en ligne sur http://www.microsoft.com/france/vision/WebcastMsdnTechDays.aspx?EID=91e693df-a4cd-461b-a104-9fb5cae6aa51.

Pour le reste, je citerai l'article de mon collègue Jacques Massa sur MSDN http://www.microsoft.com/france/msdn/windowsvista/Migrer-une-application-vers-Windows-Vista.mspx, la référence UAC MSDN traduite http://www.microsoft.com/france/msdn/windowsvista/Developpement-applications-Windows-Vista-utlisant-le-Controle-des-comptes-utilisateur.mspx, ainsi que l'excellent post de Kenny Kerr http://weblogs.asp.net/kennykerr/archive/2006/09/29/Windows-Vista-for-Developers-_1320_-Part-4-_1320_-User-Account-Control.aspx. Et bien sûr, le blog UAC http://blogs.msdn.com/uac/.

Ouac, Ouac!

To blog or not to blog

jean-yves poublan — Mon, 19 Mar 2007 10:46:00 GMT

J'ai rien à faire, je m'ennuie… Je ne vois pas d'autre solution que de blogger. Non sérieusement, c'est plutôt la pression des pairs, ou de ne pas être largué par mes mômes (c'est quoi un blog, et on poste où) ? Ou de porter renfort à mes collègues pour occuper l'espace (quel espace, y'a de l'espace sur MSDN ?)…

Non, un blog ça peut peut-être servir d'antisèche, genre oui j'avais regardé, mais je ne me souviens déjà plus (encore et toujours victime Alzheimer)… « Heureusement c'est dans mon blog » (d'habitude c'est dans mes slides, mais s'il y avait un moyen de faire sans Powerpoint, ce serait pas mal). Peut-être ca permet aussi de partager le truc de base qu'on n'a jamais compris parce qu'on n'a jamais osé demander, et que personne ne l'explique de base parce que tout le monde (sauf les nulls) le sait bien évidemment.

J'ai appris cela tôt dans ma carrière à Beaverton (qu'il vaut mieux se souvenir, pas le truc de base)… J'essayais de convaincre mon interviewer que je pourrais programmer pour lui et que justement j'avais récemment implémenté Bresenham. Malheureusement, il m'a demandé de détailler l'algorithme au tableau et j'en étais bien incapable. Puisque que c'est déjà codé, il n'avait qu'à me demander le code, non ? J'ai quand même eu le job, mais de justesse j'imagine… Peut-être a-t-il eu le pressentiment que je ne mémorisais pas les choses par cœur et que ca pouvait être une bonne chose. Il a du se dire qu'il prenait le risque que j'avais tout simplement plagiairisé ce bout de code, mais que c'était peu probable, on ne trouvait pas Bresenham sur Google. C'était en Forth sur la carte Hercules. Depuis je prends toujours mes notes Bresenham avec moi quand je me rends à un entretient. Mais ne me demandez pas comment ça marche, XAML et DirectX, ou même LineTo du GDI ça va bien, s'il faut vraiment tirer une ligne…

Bon, si vous ne voyez pas beaucoup de postes, c'est que mon boss a lu mon blog et qu'il a remédié efficacement à mon problème de temps libre...