Key Wrapping for Cryptographic APIs
Dit is een joint-work met Thomas Schrimpton over daar en Bogdan Rarinski, die op de conference is, maar ik kan het niet meteen zien. Dus laten we beginnen met een paar simpele applicaties van cryptologie. Dus e-mail-verkrijptie, je hebt het gezien van dit, ik hoop, en secure webbrowsering. Dus je hebt het zeker gezien van dit, want Björn heeft het gewoon gezegd. Dus een aantal examples, openBGP voor e-mail-verkrijptie en TLS voor secure webbrowsering. Dus dan kun je jezelf vragen hoe het werkt. Dus dit is een heel hoge niveau en ik denk dat je, omdat je hier in de audience weet van deze dingen, dus e-mail-verkrijptie, gebruikers-hybrid-verkrijptie, je zet een ephemeral-symmetraal-key en kapt het onder de publieke key, en dan gebruik je deze ephemeral-symmetraal-key voor symmetraal-verkrijptie. Voor secure webbrowsering, je hebt een ephemeral-symmetraal-key, gebruik je een handshake protocol en dan gebruik je het voor een symmetraal-key. Dus dat is heel makkelijk. De andere vraag is, waarom werkt dit? Dus voor e-mail-verkrijptie, er is de cam-dem-framer door Victor, zitten hier in de front row en Ronald. Dus in encapsulatie lijkt het als een random ephemeral-key, lijkt het als als een random ephemeral-key, en de dem is secure en de constructie is secure. Dus er is een mooie compositor hier. Er is één ding dat is secure, en de volgende ding is secure, en de hele ding is secure. En dan is er secure webbrowsering, en er is een simpel argument om te worden gemaakt, dat als de handshake protocol is secure en ook de recordleer is secure, dan is de hele ding secure. Maar het is veel harder om te argue. Dus als je kijkt naar het nummer van papieren die er na de originele papieren op de cam-dem-framer overvijzingen en het meer nodig maken, dan zijn er heelveel, als welke. Waarschijnlijk, als je kijkt naar het nummer van papieren die over de key-aangevingen en de TLS-secure, dan... Nou, ik weet niet de exacte account. Misschien heeft Kenny een indicatie op een gegeven moment, maar het is... Het is niet, ja. Dus, heel veel. Dus, op de periode van je situatie, deze compositoren kunnen worden compliceerd of kunnen worden gelijk makkelijk. Nu, de volgende vraag is waar je de key-aangeving hebt. Dus, voor e-mail-encryptie, je kunt het op jouw PC storen in memorie.  Nou, dit is problematisch, want dan, iemand, zoals Nadia, zou met een koude bootattack komen en je private key-materiaal bekijken en dat is slecht. Voor de secure webbrowser, zou je op jouw PC of in de cloud zijn. Maar er zouden liggen, dus er zouden site-channels zijn, er zouden hardblijven zijn. Dus, de keys worden gecompromiseerd. Dus, je wilt jouw key storen veilig. Dus wat je wilt doen, je wilt je keys sturen op wat het heet Hardware Security Module. Je hebt nog steeds het probleem dat betere security-policies de keys kunnen revealen, maar de idee is dat, als je een Hardware Security Module hebt, dat dit een dede stuk van equipment is en de key in staat en de equipment op de key zal opereren. Dus dit is bijvoorbeeld, dit is geen reale Hardware Security Module, dat dit de plek van een Hardware Security Module voor de purposes van dit talk. Dus er is een key in staat en dan kun je het met het opereren, maar je zal niet meer de key zien. Om het te ontdekken, moet je het command zeggen zodat het weet wat te doen is. Dus dit is wat de applicatie en programma interfaces als de API. En pkcs nummer 11 is een cryptografisch API ontdekend om te gebruiken met ACSMS. Ja? Dus hoe werkt dit? Nou, je gebruikt dit ding, je gebruikt key management om een rol te ontdekken, om een store te ontdekken, om een export te ontdekken, om transport te ontdekken, om een tire te ontdekken, symmetraal keys, of in sommige cases ook publieke keys, maar we concentreren op symmetraal keys en dan ook gebruiken ze. Want als je keys hebt, wil je ze ook gebruiken voor encryptie of authenticatie. Dus er zijn verschillende dingen die Björn heeft op zijn vorige afspraak. Dus waarom werkt dit? Nou, dat is wat we gaan praten over vandaag. Dus onze contributie is dat we een heel besproken systeem, of subset, based on a subset of pkcs 11 gebruiken een situatie waar we symmetraal keys kunnen creëren. We kunnen ook rap en unwrap gebruiken deze keys en ik zal een verder informatie hebben over rap en unwrapping later, als je het niet bekijkt. En dan kun je ze gebruiken voor avontuurlijk cryptografische operaties, omdat wat je wilt is dat je kunt laten zien dat keys die de key management gehouden kunnen gebruiken, secuurlijk.  En je wilt deze eens zien en vooral. Je wilt niet laten zien dit voor authenticatie, dan voor encryptie, dan voor authenticatie, authenticatie en encryptie, dan voor iemand die wil doen, ik weet niet wat de symmetraal keys zijn. Dus er is een niveau van abstractie die hier nodig is. Dus de technische challenge die je gaat hebben hier is dat je eerst moet komen met suitabel definities. Dus wat is de secuurlijk cryptografische primitie? Dus dit is werk dat is gedaan voordat in het context van TLS, omdat daar ook ze willen kunnen verbinden de handshake protocol of de key agreement met as many primitives as possible. Wat is de secuure cryptographic API? Dus wat is dat in tail? En wanneer is het key management secure? Dus wat zijn de requirements die je nodig van het key management systeem om te kunnen argue dat als je een secuure cryptographic primitie bent, dan krijg je een secuure cryptographic API. Nu, een van de problemen is dat er nog wel een situatie is dat keys gelegd zijn. Ik weet niet de idee is dat je gebruikt hardware security module, dus keys niet uitgaan, maar misschien keys uitgaan. En wat je wil is dat de verandering is als mogelijk limited. Je wil niet een situatie dat in een key gelegd dat dan al je secuurtie zelfs voor ongelaten keys gaat door de window. Dus dit is waarom er ook deze notion van corruptie en in sommige cases corruptie zal eigenlijk compromiseren, meer keys, want je wilt kunnen argue precies als mogelijk met keys zijn nog zeker te gebruiken en met keys zijn niet. Dus hier is een beetje historie op pkcs 11 ook om je te geven een idee van de complexiteit van het probleem van de volledige standaard te delen. Dus het begint in 95 en 20 jaar met de eerste versie door RSA en 20 jaar later de ownership van de standaard had moved tot Oasis en ze ontdekten versie 2.40. 