The state of crypto APIs - Nick Smith

thank you and good afternoon uh so I'm Nick Smith I work as a technology strategist at Talis security I've spent the last 5 years maintaining writing and using crypto apis so this is a bit of my journey really so today I'm going to start start by talking about the history of some of these apis and why we've got them and then move on to what the state-of-the-art in crypto API design is and then uh conjecture on what might cause us to evolve in the future future um you'll have to bear with the tenuous link to uh between crypto apis and evolution and I I apologize to any microbiologists in here so where did crypto apis come from

um if you go back to the mid90s um there were a number of things that happened so one of the big things that happened was at Netscape if anybody remembers them they defined the first SSL protocol um and quickly followed by version two and three and this gave birth to a library called ssle eaay which we now know as open SSL um now this started this Library started to support SSL and to be able to provide secure Communications between browsers and servers um but one of the outputs of it as well was a cryptographic API that could be used by application developers now one of the interesting things about lib SSL eaay and now open SSL is

the size of the library and the complexity in using it so about 20 minutes ago I had to look at my local copy and there was around 3,000 functions exported uh by that Library alone which is incredibly complex to negotiate and to manage and is one of the reasons why things like Libra SSL and boring SSL appeared not just because of heart bleed because the complexity in these libraries has been increasing ever since the mid90s without significant refactoring um other interesting things about this library is if you build and configure it locally still you will get functionality like md4 and md5 as well as rc2 and rc4 all of these have been um questionable for 10 15 years um so there

there's a lesson there anybody who's writing cryptographic uh applications make sure you configure open SSL correctly or Liber SSL don't just assume what you've got is secure so around the same time there was some other standardizations and libraries that appeared so the most notable and one that I am very familiar with is pkcs1 most people won't know what pkcs11 is but it's quite widespread in use it's a software interface for abstracting Hardware crypto modules so when I say a hardware crypto module this might mean a smart card or an Enterprise appliance which has been hardened um to provide cryptographic acceleration or um increased security so if you look at that in comparison to open SSL it has

much fewer functions um but has a much more limited scope on the plus side it is more coherent and generally easier to use but requires Hardware modules so then slightly later as is always the case with Windows Microsoft released their crypto API called Kappy so crypto API they got uh and but they have in fact updated that in uh crypto terms rather recently uh in 2006 with the release of Vista and their crypto Next Generation library now one thing you'll notice is a lot of these uh libraries and interfaces came out around the same time and they're all C based apis and that is because at the time C was the systems programming language which most people were still

using however the world has changed significantly since 1994 1995 but the crypto apis that are available to use have not so whilst modern-day practice is to use things like JavaScript for application development you'll still find most apis are thin shims on top of op SSL and don't do a very good job of abstracting the um complexities of that Library so we move into today and so we'll talk about some of the problems that are we're now experiencing as crypto API designers and implementers so a good example is um Quantum cryptography and being able to be Quantum safe so Google started an experiment last year to add Quantum safe key agreement to TLS um but using a algorithm and um some

premises which still require much more Crypt analysis so what they were trying to do is make sure that TLS is future prooof but maintain the security level that has now with things which are comparatively untested so to do that they ended up combining um cryptographic Primitives um and in again significantly increasing the complexity of apis so the way they did this was they took a traditional key agreement algorithm and a new postquantum one and exchanged two keys and then combin those two keys to form one Quantum resistant as well as standard um security uh key that they could use for communication but this is just an example of how the difficulty in crypto apis and now that we're living with some

decisions from the early 90s how it's becoming much more difficult for us to retrofit these things into the modern web into modern um languages so if we take what Google have done and extrapolate that a bit there is no doubt in my mind that we will need to start providing digital signatures which will be Quantum resistant so often governments will build uh Services which they hope will have a lifetime of 20 years some people think that there may be quantum computers in 20 years so we need to think about the security so if we need to start signing things with Quantum resistant algorithms which are not yet proved as well as maintain security now we're going to have to sign

them twice and what that means is we've got a real difficulty because all our apis all our serialization formats expect a single signature not two signatures so so we're at a Crossroads about what are we going to do how do we fit um how do we fit the current world with some of our previous decisions it's not all bad news thankfully so there has been some evolution in the area of crypto design um and so I'll talk about two things so firstly there's a set of new serialization formats which I'd recommend everybody who's writing uh cryptographic applications to look at and they're called the Jose standards um so previous standards which were based on a protocol or at a serialization

called asn1 which was a binary encoding new ones are based on Json and new uh languages Json is a native data structure within those fields and so what we've been able to do is bring some of the our get rid of some of our technical debt and bring some new serialization techniques which are now native to Modern applications to the new world the nice thing about these is they're human readable there's lots and lots of tools that you can get to um extract them and to look at them while if anybody who's had to work with x509 certificates will tell you that life has never always been that simple Unfortunately they didn't get rid of

x509 um for backwards compatibility reasons which is a real shame so that's why I say we evolved somewhat however the latest and biggest standardization in the world of crypto apis has been by the w3c guys behind uh standard standardizing the web and they have come out with a brand new crypto API for JavaScript which is very nice um it's got a very modern pattern for design in there so before if you again ever use open SSL pkcs1 you are prent presented with a very flat expert interface if you do if you don't know what a nons is or how to why you shouldn't reuse them you should not use that interface thankfully the guys in

the web crypto World thought about this and said okay modern application developers are going faster and faster they're not Security Experts or cryptographers we're going to split the API so there's a higher level API which is secur by default and then there's a lower level subtle API which leaves the gun loaded for you to blow your foot off should you wish don't use it unless you know what you're doing um so we've had some Evolution and that that Evolution's been in the last couple of years and that has come about by the change in the systems that we're using and as we're moving more and more towards the web we've we're having to evolve so the web and actually Cloud may

be the thing that actually forces us to completely evolve from our decisions from the midnight 90s so one of the interesting problems that people have now in business and what what developers are expecting now is to consume Services they don't consume capis uh anymore so what we we're looking at and what we think is going to happen is you're going to get um crypto as a service apis no longer will you worry about open SSL well you will but I'll get to that no but you will be doing your crypto on an external server in the cloud um somewhere else it will be using apis just like your storage apis no longer do you store files you you shove things in

your S3 bucket on AWS and forget about them and so we're going to look at a Evolution towards this model where in again instead of using op SSL pkcs1 you're going to start to use remote apis that has a number of nice functionalities such as you can centralize your crypto processing it makes things like Key Management easier but brings a whole new set of attacks into play so if you're using a service um are you really sure your TLS stack is secure really really because most people's aren't um and also you start to have to bring things like stronger authentication and authorization which an application Level has previously been quite poor and we've seen a few talks today about um securing

apis and how difficult that is when your API is your crypto service you really do have to think hard but going forward I think what we need to move on to as an industry is to provide high level apis not so many low-level crypto apis which are secur by default no longer do we want to say here's how you encrypt and this is how you write a file we need to combine them and say this is how you write a secure file this is how you upload and so that's where I believe the industry will go and we we will move higher and higher up the stack to provide security my last bullet point there is

about can we provide automated data Security based on AI can we identify threats and perform automatic remediation and encryption I'm yet to be convinced but that's where I think we might be going thank you [Applause]