De geselecteerde algoritmes moeten nu nog tot standaard verwerkt worden. Het is dus mogelijk dat deze algoritmes onderweg nog wijzigingen zullen ondergaan. De standaarden worden verwacht in 2024.

Deze tekst gaat alvast in op enkele praktische implicaties van de geselecteerde algoritmes, in hun huidige vorm. We beginnen met het algoritme voor KEM, vervolgens bespreken we de drie algoritmes voor Digitale handtekeningen. Daarna gaan we in op enkele aanbevelingen van het Duitse BSI (Bundesambt für Sicherheit in der Informationstechnik).

Key encapsulation mechanisms

Het afspreken van een gedeelde sleutel over een potentieel onveilig kanaal is een cruciaal onderdeel bij het opzetten van TLS verbindingen. Vandaag zijn zowel RSA-2048 (112 bit security) als het modernere Curve25519 (128 bit security) populaire keuzes. Die laatste is gebaseerd op elliptische krommen. Zowel cryptografie gebaseerd op RSA als op elliptische krommen is kwetsbaar voor voldoende krachtige kwantumcomputers.

Kyber werd geselecteerd als kwantumresistent KEM algoritme. Het komt in drie versies: Kyber-512, Kyber-768 en Kyber-1024, wat ruwweg overeenkomt met 128, 192 en 256 bit security. Laat ons eerst even kijken naar Kyber-512, dat in onderstaande tabel, gebaseerd op een blogpost van Cloudflare, vergeleken wordt met RSA-2048 en Curve25519.

Wat meteen opvalt is dat Kyber sleutels een pak groter zijn dan wat we vandaag gewoon zijn. Gerelateerd daarmee neemt ook de data die getransfereerd wordt tijdens de protocoluitvoering aanzienlijk toe.

De performantieresultaten mogen slechts als indicatief geïnterpreteerd worden. Niettemin stellen ze ons in staat een tweede vaststelling te maken;  de computationele efficiëntie is een pak beter dan bij Curve25519, wat, als we client-side en server-side combineren, dan weer een pak efficiënter was dan RSA-2048.

Samengevat heeft Kyber aanzienlijk grotere publiek sleutels, moet meer informatie uitgewisseld worden en is het computationeel erg efficiënt.

Het NIST heeft bovendien drie alternatieve kandidaten geselecteerd (BIKE, Classic McEliece en HQC) met als doel daaruit minstens een tweede KEM standaard te destilleren tegen 2028. Dit dient te vermijden dat we wereldwijd met de handen in het haar zitten de dag dat Kyber gekraakt zou worden. Het NIST had trouwens SIKE als vierde alternatieve kandidaat geselecteerd, maar dit werd kort daarna door onderzoekers van de KU Leuven gebroken.

Digitale handtekeningen

Voor digitale handtekeningen is de situatie minder uitgekristalliseerd. Het NIST heeft niet één maar drie algoritmes geselecteerd voor standaardisatie en heeft bovendien een nieuwe standaardisatieronde opgestart in de hoop een beter, generiek toepasbaar algoritme te vinden.

De geselecteerde algoritmes luisteren naar de namen Dilithium, Falcon en SPHINCS. In onderstaande tabel worden deze vergeleken met RSA-2048 en Ed25519, wat hedendaagse algoritmes zijn voor digitale handtekeningen gebaseerd op respectievelijk RSA en op elliptische krommen. In onderstaande tabel hebben alle algoritmes een veiligheidsniveau van ongeveer 128 bits, met uitzondering van het nog steeds erg populaire RSA-2048, wat eerder op 112 bits security gemapt moet worden. SPHINCS+128s en SPHINCS+128f  verschillen slechts in de gekozen parameters; respectievelijk worden de handtekeninggrootte en de ondertekentijd geminimaliseerd.

Afgaande op te tabel lijkt Falcon de beste van de drie kwantumresistente algoritmes. Wat de tabel niet toont is dat het veilig implementeren van Falcon enorm complex is en dat bij een nieuwe generatie processoren we daarmee misschien weer van vooraf aan mogen beginnen. Een hoge implementatiecomplexiteit gaat onvermijdelijk gepaard met een grotere kans op bugs en dus op een onveilige implementatie. De grote moeilijkheid is het uitvoeren van bepaalde (floating point) operaties in constante tijd, onafhankelijk van de inputwaarden. Dit moet vermijden dat de reken- (en dus respons-)tijd informatie zou lekken. Deze vereiste speelt echter niet wanneer de digitale handtekeningen offline geplaatst worden, zoals op pdf-documenten of digitale certificaten. In deze gevallen is Falcon dan ook een goede keuze.

Dilithium is computationeel efficiënter en is – in tegenstelling tot Falcon – vrij eenvoudig veilig te implementeren. Helaas resulteert dit algoritme in aanzienlijk grotere publieke sleutels en handtekeningen. Dit zal een impact zal hebben op bijvoorbeeld TLS handshake protocols, om een veilig kanaal tussen twee partijen op te zetten, bijvoorbeeld wanneer u naar een webpagina surft.

SPHINCS, ten slotte, resulteert in enorm grote handtekeningen en ook het handtekenen zelf is erg zwaar. Ook verificatie van digitale handtekeningen is niet geweldig. Het heeft wel als voordeel dat de publieke sleutels erg klein zijn en dat het steunt op een erg solide en goed gekende aanname uit de cryptografie.

X.509 certificaten zijn vandaag de standaard om een publieke sleutel te koppelen aan een identiteit. Op uw eID kaart, bijvoorbeeld, staan twee dergelijke certificaten; het ene stelt u in staat om digitale handtekeningen te plaatsen, het andere laat toe u op een sterke wijze te authenticeren. Ook voor het opzetten van een veilig kanaal beschikt deze website (website.smalsrech.be) over een X.509 certificaat. Welk van bovenstaande algoritmes ook toegepast wordt, X.509 certificaten op basis van kwantumresistente cryptografie zullen sowieso een pak groter worden dan wat vandaag het geval is; Een X.509 certificaat bevat immers sowieso een publieke sleutel én een digitale handtekening. Ook voor authenticatie van machines of personen kan onderliggend beroep gedaan worden op algoritmes voor digitale handtekeningen. Dergelijke authenticatie zal, wanneer gemigreerd wordt naar de geselecteerde algoritmes, aan efficiëntie verliezen.

Samengevat is er voor elk van de drie door het NIST geselecteerde algoritmes wel een of ander stevig nadeel. De keuze van het algoritme zal dan ook afhangen van de toepassing. Bovendien zijn deze algoritmes systematisch trager dan wat we vandaag kennen. Dit gebrek aan een efficiënt en generiek bruikbaar kwantumresistent handtekeningschema noopte het NIST ertoe een nieuwe standaardisatieprocedure op te starten. Vergeet niet dat Dilithium, Falcon en SPHINCS in 2016 ingezonden werden en we ondertussen toch weer een aantal jaar verder zijn.

Aanbevelingen

Het Duitse BSI (Bundesambt für Sicherheit in der Informationstechnik) kwam vorig jaar met een aantal aanbevelingen met betrekking tot kwantumresistente cryptografie. Een eerste is die van cryptoagility, waarover het BSI schrijft:

In the development of new and the maintenance of existing applications, particular attention should be paid to making the cryptographic mechanisms as flexible as possible in order to be able to react to all conceivable developments, implement upcoming recommendations and standards and possibly replace algorithms in the future that no longer guarantee the desired level of security (“cryptoagility”).

Een belangrijke eigenschap van de geselecteerde algoritmes is dat dezelfde API als voorheen gebruikt kan worden – weliswaar met andere parameters –, wat migratie alvast vergemakkelijkt.

Meer opmerkelijk is de aanbeveling om voorlopig enkel hybride oplossingen toe te passen:

The quantum computer resistant algorithms that are currently being standardized are not yet analyzed as well as the “classical” algorithms (RSA and ECC). This is especially true with regard to weaknesses that become largely apparent in applications, such as typical implementation errors, possible side-channel attacks, etc. Therefore, the BSI does not recommend using post-quantum cryptography alone, but only “hybrid” if possible, i.e. in combination with classical algorithms.

Dit heeft uiteraard een impact op de bytegroottes, op de getransfereerde datavolumes, en op zowel de performantie als de complexiteit van de oplossingen. Dit is een aanbeveling die wellicht op termijn zal verdwijnen, maar voorlopig maakt het migratie naar kwantumresistentie er niet aantrekkelijker op.

Hoe verder?

Volgens sommige experten – al zijn de meningen verdeeld – moeten we dringend migreren naar kwantumresistente cryptografie en komen de NIST standaarden zelfs wat te laat, ook al is een bedreigende kwantumcomputer nog vele jaren van ons verwijderd. Daarbij wordt verwezen naar een aanval waarbij vandaag vercijferde data verzameld en bewaard worden, met als doel deze te decrypteren eens de (kwantum?)technologie dit toelaat.

Anderzijds is er nog werk aan de winkel is. Het vertrouwen in de nieuwe standaarden moet nog groeien en in het geval van digitale handtekeningen is het NIST nog steeds op zoek naar de heilige graal.

Eens een standaardisatieronde voltooid is, zal het wellicht geïntegreerd worden in allerlei services, producten en libraries, zoals TLS libraries. Services met TLS kwantumbreekbare verbindingen zullen dan vroeg of laat een lagere ranking of strenge aanbevelingen krijgen, bijvoorbeeld bij de erg populaire test van SSL labs of in auditrapporten.

Voorlopig is migreren nog niet aan de orde. Wat wel aan de orde is, is het toepassen van het eerder vermeldde cryptoagility om een latere migratie te faciliteren.

Dit is een ingezonden bijdrage van Kristof Verslype, cryptograaf bij Smals Research. Het werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Afbeelding: Darwin Falls, Tim DonnellyFollow, CC

Dans le cas des algorithmes de chiffrement symétrique, la taille des clés à choisir est directement liée à la complexité d’une recherche exhaustive. Par exemple, pour retrouver une clé du DES (ancien standard de chiffrement), soit 56 bits, il y a 2⁵⁶ clés possibles. En 1977, date de l’adoption du standard, les essayer toutes était impossible et c’est resté le cas pendant 20 ans ; mais en 1997 pour la première fois le groupe DESCHALL Project a réussi une recherche exhaustive de clés. En 2001 le nouveau standard AES a été adopté ; il utilise un design différent du DES et permet des clés plus longues (de 128 à 256 bits). Pour retrouver une clé AES de 128 bits, vous aurez besoin d’essayer 2¹²⁷ clés en moyenne (il y a 2¹²⁸ clés possibles et en moyenne vous trouverez la bonne au bout de la moitié de vos essais). Même en investissant de gros moyens techniques (cloud computing, hardware dédié) et financiers, je parie que vous n’y arriverez pas!

Dans le cas des algorithmes de chiffrement asymétrique et des algorithmes de signature digitale, la taille des clés à choisir dépend des propriétés mathématiques de l’algorithme et il existe de bien meilleures attaques que la recherche exhaustive. Par exemple, dans le cas de RSA, factoriser le module N de la clé publique permet de retrouver la clé privée. A l’heure actuelle, la taille minimum acceptable pour de telles clés est 1024 bits et la taille recommandée est de 2048 bits (à adapter en fonction de la durée de vie souhaitée de la clé).

Il est déjà arrivé qu’un choix de clé trop courte permette qu’un système sécurisé soit attaqué. Un exemple qui a fait grand bruit en France est celui de l’affaire Humpich. En 1998, l’ingénieur français Serge Humpich parvient à casser la Carte Bleue, carte bancaire à puce, et à fabriquer une fausse carte.  Au cœur de son attaque réside le fait que la clé publique utilisée pour l’authentification de la carte (l’étape lors de laquelle le terminal vérifie que la carte est authentique grâce à une signature digitale stockée dans la carte) était une clé RSA de 320 bits. Pour casser cette clé (c’est-à-dire retrouver la clé privée correspondante), il fallait factoriser un entier de 320 bits, ce qui était relativement rapide à faire en 1998 avec un logiciel adéquat et un ordinateur de l’époque. Une fois la clé privée retrouvée, facile de générer une signature digitale falsifiée…

Les serveurs SSL aussi ont besoin de clés (clés de chiffrement RSA) et étant donné leur prolifération ils permettent une étude intéressante. Grâce au site SSL Pulse créé par le Trustworthy Internet Movement, on peut avoir des statistiques précises sur les clés utilisées sur les sites les plus populaires. Au 23 mai 2012, sur 200 000 sites testés, seuls 5 sites utilisaient encore des clés de moins de 1024 bits ; 16% utilisaient des clés de 1024 bits, et les 83,9% restants utilisaient des clés de 2048 bits ou plus. On voit donc que, si la sécurité de ces serveurs laisse parfois à désirer comme le révèle SSL Pulse, ce n’est pas à cause de la taille de clés mais plutôt à cause de problèmes de configuration (support de versions anciennes de SSL, mauvais choix de suites de chiffrement, etc..).

En pratique, si vous devez choisir une taille de clés et que vous avez le moindre doute, faites appel à un expert en cryptographie. Cet expert pourra se référer au site KeyLength.com qui compile différents travaux sur le sujet. Ces travaux ont étés effectués par des organisations comme le NIST (National Institute for Standards and Technology) américain, le BSI (Bundesamt für Sicherheit in der Informationstechnik) allemand, le réseau européen d’excellence ECRYPT et d’autres. Sur ce site, à l’aide de différents tableaux, on peut recevoir une recommandation de taille de clés en fonction de plusieurs paramètres, comme le type d’algorithme, la durée de vie de la clé souhaitée, et le niveau de sécurité voulu.

Un navigateur doit, pour pouvoir établir une connexion SSL avec un serveur web, obtenir la clé publique de ce serveur. Il doit, en plus, avoir confiance en cette clé publique, c’est-à-dire s’assurer qu’elle est l’authentique clé publique de ce serveur. Pour cela, on utilise des certificats. Le serveur possède un certificat et l’envoie au navigateur. Ce certificat est un fichier qui contient entre autres l’identifiant du serveur, la clé publique du serveur et des dates de validité. Le tout est signé par un tiers de confiance, appelé Autorité de Certification (Certificate Authority ou CA), qui joue un rôle fondamental. Le navigateur maintient une liste des clés publiques des CA en lesquels il a confiance ; grâce à ces clés publiques, il peut vérifier l’authenticité du certificat du serveur.

Ce modèle repose donc sur la confiance en une liste déterminée de CA. Or, l’actualité récente montre une certaine fragilité de cette approche. En effet, a plusieurs reprises, des brèches de sécurité ont permis à des hackers de compromettre des CA, le cas le plus parlant étant celui de DigiNotar, aujourd’hui en faillite après que des attaquant aient réussi à forger de nombreux faux certificats.

Certains chercheurs étudient donc des alternatives. Il ne s’agit pas d’alternatives au protocole SSL en lui-même mais bien d’approches différentes pour établir la confiance. Le problème du modèle actuel basé sur les Autorités de Certification est qu’il n’est sûr que si toutes les autorités sont sûres ; autrement dit, il suffit qu’une seule autorité soit compromise et le système ne garantit plus une bonne sécurité.

L’une de ces alternatives est Convergence, proposée par Moxie Marlinspike, expert en sécurité. Le principe est simplement de remplacer les CA par un réseau de notaires et de donner à l’utilisateur le choix de faire confiance ou non à certains notaires. Chaque notaire décide de donner sa confiance à un site ou non. Lorsque le navigateur arrive pour la première fois sur un site en https, il demande le certificat du site, puis demande à tous ses notaires de confiance d’attester de l’authenticité du certificat. Si tous les notaires répondent “oui”, alors le navigateur considère le certificat comme valide. Il s’agit donc d’une approche distribuée de la confiance ; avec Convergence, il n’y a plus de Single Point Of Failure.

Que penser de Convergence ? A l’heure actuelle, on manque de notaires (une cinquantaine environ), or une masse critique de notaires sera bien sûr nécessaire pour que le système fonctionne. Et ce système pose des questions : comment vont travailler les notaires ? A l’heure actuelle, l’administrateur d’un site web qui veut obtenir un certificat peut choisir une autorité de certification pour passer commande d’un certificat. Mais comment enregistrer ce certificat auprès des notaires ? Enfin, pour l’instant, Convergence pour l’utilisateur est uniquement disponible pour le navigateur Firefox, sous la forme d’un add-on. Celui-ci ne fonctionne pas “out-of-the-box”; après un rapide test, mon navigateur ne connaît que deux notaires et n’arrive plus à se connecter en https à mes sites favoris… Utiliser Convergence va demander plus de travail de configuration à l’utilisateur, et l’on peut s’imaginer qu’il va d’abord convaincre les utilisateurs les plus avancés et sensibilisés à la problématique des certificats.

L’idée de Convergence est séduisante. Mais il va donc falloir lui laisser un peu de temps pour se développer.

En pratique, ces fonctions servent à calculer une empreinte d’un message ou document, et on traite cette empreinte comme si elle était unique (puisqu’il est impossible de trouver un autre message ou document qui aurait la même empreinte).

Les fonctions de hachage sont très utilisées en cryptographie. Elles servent par exemple dans les algorithmes de signature digitale pour condenser le message avant de transformer ce résultat en signature à l’aide de la clé privée.

Parmi l’ensemble des fonctions de hachage existantes, deux ont été particulièrement utilisées dans de nombreuses applications : MD5 et SHA-1. Mais leur sécurité a été remise en cause par les progrès récents des recherches en cryptographie. Dans le cas de MD5, dont les empreintes font 128 bits, des chercheurs ont trouvé une collision en 2004 (elle n’est donc « plus » résistante aux collisions !), et dans le cas de SHA-1, des vulnérabilités ont été décelées dès 2005. Ces vulnérabilités n’ont pas encore permis de trouver des collisions. Il n’y a pas à paniquer si vous utilisez une application qui implémente SHA-1, mais les architectes doivent désormais plutôt choisir une fonction de la famille SHA-2 (SHA-224, SHA-256, SHA-384, ou SHA-512). Et, à long terme, c’est une bonne idée d’anticiper et de concevoir une fonction de nouvelle génération appelée à devenir le prochain standard, SHA-3.

C’est le NIST (National Institute of Standards and Technology), organisme d’état qui dépend du ministère du Commerce des Etats-Unis, qui a lancé une compétition internationale pour choisir quelle sera cette fonction de hachage SHA-3. Cette fonction sera inscrite dans le « Federal Information Processing Standard (FIPS) 180-3, Secure Hash Standard ». La procédure en plusieurs tours est comparable à celle que le NIST avait auparavant employée pour le choix d’AES (Advanced Encryption Standard). Elle a consisté  à lancer un appel en novembre 2007, auquel n’importe quelle personne ou organisation pouvait répondre pour suggérer une fonction de hachage. Beaucoup d’équipes de chercheurs en cryptographie ont répondu à l’appel. Ensuite, à chaque tour, certaines fonctions sont choisies, selon des critères de performance et de sécurité.

• Lors de la clôture de l’appel, le 31 octobre 2008, 64 candidatures avaient été reçues.
• Le premier tour a commencé le 1^er novembre 2008. Au 5 décembre 2008, il restait  51 fonctions qui satisfaisaient aux exigences minimales. Après une conférence et plusieurs débats, 14 parmi ces 51 ont été retenues pour le deuxième tour.
• Le deuxième tour a commencé le 24 juillet 2009. Les performances et la sécurité des candidats restants ont été examinées pendant un an par la communauté internationale et une conférence a été organisée en août 2010. Le 9 décembre 2010, cinq candidats ont été retenus pour le troisième tour.

A l’heure de ce message, le troisième tour est en cours. Il reste donc 5 finalistes, nommés BLAKE, Grøstl,  JH, Keccak et Skein, et nous sommes dans la période lors de laquelle le public peut s’exprimer sur ces finalistes (par exemple, s’il trouve une faille de sécurité dans l’un des candidats). Au printemps 2012 aura lieu la dernière conférence SHA-3 et le choix du vainqueur sera annoncé plus tard en 2012.

Nous connaîtrons donc bientôt une nouvelle fonction de hachage standard, SHA-3, dont la sécurité et les performances auront été validées par une communauté internationale d’experts en cryptographie.

Wegschrijven van gegevens naar de kluis

Kort komt threshold encryptie neer op traditionele asymmetrische encryptie met één publieke encryptiesleutel maar met twee private decryptiesleutels.  Het schrijven van een medisch dossier naar de “kluis” (de plek waar alle dossiers centraal worden opgeslagen) gebeurt op traditionele manier. Elk veld wordt apart aan de hand van een telkens unieke symmetrische sleutel vercijferd.  De symmetrische sleutel zelf wordt aan de hand van de publieke sleutel van het systeem, vercijferd:

Lezen van een dossier uit de kluis

Het lezen van een dossier is echter verschillend van standaard asymmetrische encryptie, en geschiedt in 3 fases:

1. De dokter vraagt een dossier op in de kluis en ontvangt de vercijferde unieke sessiesleutel, samen met de data vercijferd met deze sleutel
2. De vercijferde unieke sessiesleutel wordt naar 2 verschillende partijen gestuurd – elk met hun eigen private key – die een deel van de decryptie voor hun nemen.
3. De dokter combineert de twee delen tot een ontcijferde unieke sessiesleutel, waarme de werkelijke gegevens ontcijferd kunnen worden.

Merk dus op dat de gegevens enkel zichtbaar zijn bij de dokter en dat géén gegevens (zelfs niet vercijferd), door een van de externe partijen, vloeien.  Het is op dit gebruik van threshold encryptie, dat een patent is genomen.

]]>