 Bonjour tout le monde, je suis Ben, je travaille à Inria et à Paris et aujourd'hui je veux rappeler un peu sur le travail que nous avons fait cette semaine entre une collaboration de recherche qui s'appelle « Project Everest » de Microsoft et de Inria, avec des gens de Mozilla en intégrant le Libre Crypto-Hackle Star dans Firefox. Ok, nous avons des applications de sécurité qui utilisent le crypto. Normalement, les effets dans ces applications de sécurité ne sont pas dans le crypto, à la plupart du temps en fait, mais l'idée est qu'on encore veut mettre bien implémenté, théoriquement, les primitives de crypto pour ces applications. Tout le monde sait ici qu'il y a des classes principales des erreurs d'implémentation, typiquement les questions de sécurité, les questions de sécurité fonctionnelles, les questions de sécurité – « buffa hover flow », « buffer hover run » – après « user for free » – « Earth片 lack attacks ». À 4 sites, vous pourriez savoir attacks comme le Lucky 13, des choses comme ceci, ou le beau emkirigovsre-attack qu'on voit du comité de Mercedes. Et les questions de sécurité fonctionnelles sont dans l'histoire, Vous n'êtes pas implémentairement le comportement spécifique de votre code. C'est un exemple d'exemple d'exemple de correcteur fonctionnel. Comme vous pouvez le voir, c'est un bug dans OpenSSL en 2016 où il y a un bon commentaire sur le bouton qui dit que cette addition n'est pas sur la surface. Bien sûr, ça peut. Il y a beaucoup de questions de correcteur fonctionnel. Il y en a une récemment dans NSS. L'idée est qu'il n'est pas nécessairement as trivial d'exploiter les issues de sécurité. Mais c'est un issue correcteur, donc à un moment, quelqu'un de très clair quand il n'est pas un erreur correcteur, quelqu'un de très clair peut l'exploiter. Ce qui est surprenant est que même le software qui est créé pour être facile à utiliser et à être implémentairement, c'est vulnérable pour ces types d'offres. Il y a des gens très bons qui sont en train de créer un très bon code de cryptos, et qui sont très intelligibles dans ce qu'ils font. Et même ceux qui peuvent me faire l'exploiter. Donc nous avons vraiment besoin d'un truc pour l'aide. Alors, nous allons introduire NSS. C'est un effort joint de Mozilla, Red Hat, et beaucoup d'autres pour implémenter la libraire de sécurité dans CC++ et c'est la libraire de sécurité utilisée dans Firefox. C'est aussi utilisé dans beaucoup d'autres places, Rail, Fedora, BSD, etc. Il y a un grand nombre de primitives de législation et de nouvelles primitives, bien sûr. Ce n'est pas le cas avec les clients qui ont besoin d'avoir des primitives. NSS aussi implique des protocoles, comme TLS et DTLS, et des IPIs comme WebCrypto, PCS, etc. Mais à un moment, dans les dernières années, comme OpenSSL a fait, comme beaucoup d'autres libraires ont fait, les gens ont dit, NSS est allé, il y a des codes de législation, donc nous devons travailler sur ça. Qu'est-ce qu'on peut faire sur ça? On peut faire un progressement moderne, afin d'avoir plus de confiance en ses correctes. Au début, il n'y avait pas vraiment une bonne façon de procéder, donc tout le monde a discuté et peut-être que nous pouvons redesigner la libraire pour que tout le code de législation soit réglé par des clients, donc ce n'est pas facile. Il y a peut-être plus d'argent, plus de libraire, mais les teams de crypto sont très petites, donc c'est très difficile de redesigner ce genre de choses. Donc la décision a été de prendre la libraire étape par étape et de replacer des parts de la libraire pour obtenir la confiance en ses correctes en utilisant la libraire. Et en fait, c'est intéressant parce que dans Real World Crypto, en 2015, Emilia Casper a sorti un challenge de recherche pour tout le monde à l'académie, disant que c'est sympa si nous pouvons utiliser la libraire en crypto. Et exactement en même temps, beaucoup de personnes ont commencé à penser que nous avons déjà des méthodes formales pour faire des choses avec ça. Peut-être que c'est temps de appliquer ces techniques pour les libraires cryptographiques. Donc il y a beaucoup de papiers pour beaucoup d'outils, VST, crypto et CTV, s'il y a beaucoup d'outils qui sont appuyés. Et Mozilla a commencé à penser à ça, en disant « OK, on va faire des méthodes formales » et la question naturelle, quand vous commencez un projet de vérification, c'est ce genre de vérification que vous faites et où vous procédez. Il y a deux main questions que vous devez poser. Qu'est-ce level de code que vous devez vérifier ? Vous devez vérifier l'assemblée, vous devez vérifier le level C, vous devez vérifier les langages de l'IOR, et vous devez vérifier et ces questions ont un impact sur la façon dont vous procédez dans le futur. Donc typiquement, ce qui est intéressant c'est que si vous devez aller de l'assemblée de l'IOR, vous devez avoir confiance dans le sens que vous devez vérifier les compétences, vous avez une meilleure performance et vous avez une meilleure garantie de site parce que vous devez descendre mais sur l'autre côté si vous devez aller vers les langages de l'IOR vous devez avoir des choses comme l'effort profilé parce que les langages de l'IOR sont plus expressifs donc c'est plus facile de vérifier les correctes etc. Donc dans cette façon, ce que nous avons fait c'est que d'avoir sa propre langage de l'IOR c'est un langage pure fonctionnel qui s'appelle FSTAR donc prendre l'approche de la langage de l'IOR et générer des codes C pour que nous puissions compenser et dire qu'on peut utiliser des vérifications de l'effort profilé avec les langages de l'IOR et nous pouvons aussi avoir plus de performance sur les codes C plus de garanties de site nous n'avons pas de temps nous n'avons pas de collection garbage nous n'avons pas de code C et c'est très portable parce que tout le monde peut voir donc dans cette façon comme part de le projet QRS nous avons implémenté cette bibliothèque de l'IOR et la idée est qu'il y a une spécification de l'IOR et nous voulons exécuter quelques codes efficaces donc nous allons lier les deux ensemble l'idée est qu'on a un bon spectacle c'est facile à lire c'est pure fonctionnel et vous avez les codes efficaces donc les deux sont dans les mêmes langages et ensuite vous extracterez des codes C donc l'idée est pour ces 4 codes c'est d'abord de prendre quelques codes cryptos comme un NIST ou un NFC et ce que vous allez faire c'est que vous allez écrire une spécification formale en FSTAR donc la spécification pure, le site n'a pas d'effects très concis, très réellible et ensuite vous allez prendre le state de code de l'IOR qui est là-bas et ce que vous allez faire c'est d'abord de substater FSTAR pour que vous ayez des codes efficaces en FSTAR l'idée est que vous allez relâcher les deux et pour faire ça il y a ces 3 classes d'issues que nous avons donc ce que nous voulons faire c'est d'actuellement dire que les codes efficaces vont vérifier certaines propriétés donc typiquement la sécurité de la mémoire fonctionnel correct de la spécification de la spécification formale et quelque chose que nous appelons la spécification de la spécification parce qu'actuellement nous n'aiment pas les termes constants ce que vous faites quand vous faites la spécification de la spécification c'est d'actuellement qu'on n'aie pas d'utiliser des secrets sur certaines opérations vous n'aurez pas d'utilisation de diviser par des valeurs secrètes vous n'aurez pas d'indexes sur des valeurs secrètes vous n'aurez pas d'utilisation sur des valeurs secrètes vous n'aurez pas d'utilisation et typiquement nous renforcons que ce code stateful n'est pas respecté par ces 3 classes de propriétés et quand vous avez la vérification vous avez un code Fstar qui est vérifié pour ces propriétés et ensuite vous vous dites ok, c'est bien mais je ne peux pas faire ça, je veux générer un code C donc pour faire ça nous avons un compiler qui s'appelle Camlin qui est en train de prendre cette code Fstar passant par une série de transformations qui sont formelées et nous avons un théorème correcteur pour ce compiler qui dit ok, j'ai le code Fstar j'ai le code C si le code Fstar renforce ces 3 propriétés alors j'ai le code Théorème qui dit qu'il y aura une préservation de la préservation de la code C et ces 3 propriétés seront propagatées par la compilation et nous avons réussi à trouver des résultats donc c'est le table des algorithmes principaux que nous avons en colère maintenant nous avons beaucoup de fonctionnalités comme les habitudes qui sont utilisées dans les standards c'est suffisant d'impliquer l'application solte et comme vous pouvez le voir nous avons la spécification qui est la totale de 800 lines donc c'est très très court c'est très très simple et puis vous avez sur le couloir sur le gauche sur la droite le code state retenu en Fstar vous pouvez voir que c'est beaucoup plus grand parce que quand vous faites un plus de mathématiques sur les big numbers si vous voulez l'impliquer c'est une addition de big num donc vous devez faire beaucoup de choses le code state also contains the proofs so it's much bigger and once you have this you verify the functional correctness and the three processes you can go through the cramling compiler and extract the C code which is much smaller because you remove everything that is not computationally relevant so typically the proof disappears and the verification time is quite good actually it's it's 3 hours but the thing is we have techniques so that we can actually run the verification in 20 minutes so here's an example it's not necessarily for reading the idea is that that's the full specification of poly 1305 written in Fstar so it reasons about the mathematical integrers it does field arithmetic etc and in 40 lines you have the full definition of what's the poly 1305 algorithm now how does the stateful code look like that's the nice question of course it's much more ugly the idea is that still you will have a separation between the type which is the first part on the top of the screen the signature that will say ok this is a function that takes some arguments it lives in the stack effect so it's stateful it returns unit returns nothing it has some memory safety conditions which is typically a liveness of the memory which would correspond in C as the pointer is not new for instance and you have the math specification which says that the result of this computation done by this body of the function is actually the correct specification the correct result and then you have the code and the proof which will disappear after compilation so you can see that the code is preserved but all that proof disappear from the sequence so in Firefox we decided to integrate the two curve 2.5.9 algorithm first and it's in production in Firefox content since November we already have more primitives in Firefox right now so if you're using netli you already have verified chacha verified poly and the next batch of primitives is actually we are integrating more and more primitives the interesting question of course is how does one go from an academic project to production industry so there are many constraints typically one of the main constraints is obviously performance another constraint is readability reviewability of the code integration to integration because you want to all the process to be inside the tool integration of Mozilla and you obviously have to keep support for many use cases so regarding performance so you can see that for Hucklestar curve 2.5.9 it's actually very fast it's typically we could show that it's 20% faster than the previous NSS code well it's verified for many reasons but because we ported the code from Adam Langley's curve 2.5.9 code but we could statically prove that there was one carry that was actually not necessary in the Bingdom computations so it's slightly faster but roughly it's the same speed and then you have the old funny part the code review part where you have people that say ok yeah but what is that thing like the big old where nothing happens in the code which is not really un written code it's not very nice but still you have to do this kind of process where we improve the criminal compiler to remove empty branches remove un reachable code etc and actually we can always see the difference so you don't really see the colors here but that's not important on the left side is the code that is currently in production in Firefox 57 on the right code is actually the code that is in Firefox nightly because in the meantime we kept improving the compiler the fstar2c compiler so we have many improvements that are done usually one important point is that Mozilla wanted to be able to run verification without us they want to be something standalone that they can master things and they want to actually verify the code in their CI so what we did is to make sure that we integrated the whole verification tool chain inside the Mozilla CI so it's done by Docker image actually take the commit for the current ACL star version run the verification on it run the extraction on it and compare the C code to the code that is actually in production that's interesting because they can ensure that it's verified but they can also ensure that there is no difference between the code in production meaning that if someone edit manually the C code when pushing a commit in NSS the ACL tool chain will say but no this code is not verified so you can't the CI will tell you the way so there have been many interesting things I don't have time to develop on everything but typically supporting multiple platforms is actually a challenge because outside the verified code you actually use NSS libraries or things like this that are platform specific we push new code into Firefox we got people from for instance Solaris in that case that said oh yeah but this is not working for us so we ask them ok but we don't have all the clients are not in the Mozilla CI not all of them because it's impossible to list everything so they provided us a patch and the patch was actually wrong so it's not in the verified code it's like something else but still you have this kind of the contributors have to contribute to some code to support some platforms and things like this and it can lead to problems hopefully it's very easy to sort of solve those problems efficiently because of the cycle of production where you push to 40 40 000 people then you push to 2 or 3 million people and then you push to multiple hundreds of million people so to do that the question was super important that's clearly the most important part and most important lesson of this collaboration is that we have to find a middle ground for everything like for most of the thing at least we need to find a middle ground so we did find a common workflow which was the workflow that we have through Everest also the idea is that we want FSTAR specification we write the stateful code we prove the stateful code correct regarding to the specification we extract the C we test the C once we have the verified C code we go through all the Mozilla CI formatting, auditing they also review the specification they review the C code and the specification there is an interesting reason for that is that you don't necessarily need to trust the tools the tool chain so you actually want to review the C code obviously but the idea is that since you want to trust more and more the tool chain you review the specification you review the C code and that's enough to convince you that knowing that obviously the C code review is much more important when you don't trust the tool chain then obviously you take the C code you run it for CI it will run the verification locally in the CI run tests because you with Mozilla tests the left part is not the right part is not important it just to show that there have been many improvements and things that we add to there is a huge list of things that we have to do so that we can put the code in production so we can discuss more about the questions after so what's next the idea is that it's good to have verified efficient code but NSS still needs some work it needs removing some C code maybe a good idea would be to actually introduce other forms of formal methods because you don't necessarily want to rely on only one you can actually get the generated C code from FSTAR and you verify it using other tools like VST or crypto and then there is something also interesting which is we could integrate formally verified assemblies typically the one that we already have for Everest or other different verified assembly implementations and in the future if the technology goes well we can build on top of that and that sort of the motto of Everest and METLS which is verifying protocol level things or parser the future of FSTAR it's obviously implementing more primitives we already have a bunch of primitives but we want to have ASAPSS AES, GCM P256 the new scores because those are very used so we want to have them and the main general idea is to reduce the trust in the tools reduce the proof effort which is something that is very important and already between let's say last last January and right now we had a lot of efforts towards having more usable tools so that it's actually now much faster to implement verified to primitives than it was before and I think that's one of the reasons of the success of having a complete but I mean something reasonably well as a crypto library echo which has many primitives is because we can scale it up and it's not always the case that tools can build upon the things that they are already doing so it's very important to reduce the proof effort for that matter and supporting more protocol more platforms the IoT platforms for instance would be a good idea and why not because it extracts to many languages it extracts to C but it also extracts to a sharp and to a camel why not extract to WebAssembly so there are many things that we can do but I think extracting C code is actually very important and it's probably going to remain it's probably going to remain the focus of Apple star and an SS for the future well I skip many things but if you have any questions we can definitely go back to it thank you go ahead so you talked about now there's some trust in your tools but there's also some trust remaining in the spec so I was wondering in the workflow how often did you have to how often did you have to update the spec how hard is it to write a correct spec for something like 255.19 because that's still at the end we still have to trust that that is correct so the spec is actually the part that you can't you can't make a mistake here so what's interesting since Fstar extracts to OCaml what we do is the spec can be run so we extract to OCaml and we pass all the test vectors at the specification level obviously that's not enough but as you could see for the for the correct for the language of the specifications is actually since it's a strongly type pure language it's relatively easy to do good specifications so of course like everybody can do mistakes sometimes you have to iterate and say ok this thing is actually wrong that's why it's the most important part to review but obviously it's if you mess up the specification voilà so you eternally have this problem of having to trust something yeah more questions ok just one quick question I'm sorry if I missed it but who is doing most of the specification writing and coding was it Mozilla developers or researchers it was projective developers for the specification and the proofs and all the integration parts was mostly guided by the NSS team and the Mozilla people including all the changes that were to be made to the code so that we can obtain c code that is actually readable and available for production ok yeah just behind you well there's someone up there and you're supposed to go to Mike so getting chastised yeah go ahead question about your perspective on the generated c code so for example you're the example with the empty branch that's caught in code review from another perspective the c is essentially being used as an IR for the high level specification so I'm wondering like to what extent do you feel that it's necessary to do code review on the generated code and make it readable rather than just saying well our like real source code is up here and that is a generated artifact so exactly we know that it's an artifact so what we do is actually we have to go through the c code especially because we produce only a few thousands of lines of verified c code right now so sometimes you have corner cases the only scene for very specific cases in the extraction so I think we have a general pattern of reviewing everything that comes out from the from the crimine compiler so that we actually see what are the defects and usually once you fix one small thing it's all the generated c code you just regenerate everything it takes a few seconds and all the new code is free of those defects so I think it's a necessary cycling that you go to the generated c code and if you can if you must touch the compiler you touch the compiler so that it's generating different code and usually we don't have too much to edit the original fstar stateful code that doesn't happen too much that does happen for variable names or things like this but we don't do it too much actually but it's a good thing to cycle from the generated c code ok so I think we'll cut it off there and take the rest of the questions offline very cool work and let's thank the speaker again