Anastasiia Voitova on Cryptography and the Design of Cryptographic Libraries

What appealed to you about making the transition from mobile to cryptographic libraries?

• 1:45 I was writing iOS applications for six or seven years; it’s really exciting, but you’re dependent on the platform itself.
• 2:05 At some point, I realised that a lot of mobile developers don’t actually care about user privacy or security at all.
• 2:40 When I use an application and have personal data, I wasn’t sure if the information would be securely stored.
• 3:00 I gave some talks to fellow developers about security concepts.
• 3:10 You cannot just make applications secure without making the infrastructure secure.
• 3:20 Mobile apps don’t live in a vacuum - they have some kind of server-side or cloud database.
• 3:35 Putting effort inside the app but forgetting about the infrastructure won’t make your system secure.
• 3:45 So I switched from developing the mobile all to designing the system as a whole, and at some point I was spending more time on security than features.

What is your focus today?

• 4:00 I’m working on an even more narrow focus these days - I’m working on cryptographic libraries; some open-source, some commercial.
• 4:40 All of our software has some kind of crypto core, which is often written in C, but it won’t be usable from client applications if we only have C bindings.
• 4:55 So it has wrappers in higher level languages, and this is where I put a lot of my efforts in.
• 5:15 The main focus is how the developers use the software, and what they think when they are building secure software and what the limits are.
• 5:40 So I run some user interviews with them to find out how we can improve our product.

What kind of libraries do you create?

• 6:15 It’s middleware - we don’t create our own crypto libraries.
• 6:25 We use providers like OpenSSL, BoringSSL, LibreSSL and so on.
• 6:30 What we do is make OpenSSL easier to use, solving the exact use cases for the platform.
• 6:40 For example, libsodium has a nice abstract secure box - if you want to store data securely, put it in a secure box.
• 6:50 What they do is add symmetric encryption and integrity checks.
• 7:00 As a developer, you don’t need to write it on your own - you can put data in the secure box.
• 7:05 We are aiming to be something similar; to make it easier for developers to solve their high-level use-cases.
• 7:30 As an example, look at IS encryption.
• 7:35 To use IS to encrypt or decrypt things with OpenSSL, you need to understand concepts like key, lengths, cipher modes, padding and initial vectors.
• 8:00 You need to put all of these things into the function which encrypts the data.
• 8:05 That’s a lot of things to decide, and have opportunities for making mistakes.
• 8:15 Developers don’t generally have a lot of experience with security knowledge.
• 8:30 We hide all of these complicated things and offer a simplified encrypt and decrypt interface.
• 8:40 The developers can be safe in the knowledge that the padding is correct, and the cipher mode and key lengths are suitable.
• 8:50 All of these are solved by our wrappers - you just have to call encrypt.

How do you design the choices to be correct?

• 9:00 We have real cryptography PhDs in our company, so we know we are making the right choices.
• 9:20 We also do this in the open as well - because you can know if something is secure if it is open.
• 9:30 We publish everything and ask the security community to review, along with white papers.

So the choices are pre-made in the library rather than dependent upon the task at hand?

• 10:15 Developers have a use-case that they want to solve and a set of constraints, like being able to store data and preserve length.
• 10:25 Or to store data securely without length restrictions.
• 10:30 Or to define access so that you can share it to different parties, and encrypt the data but share it in a secure way.
• 10:50 These are high-level use-cases, and we provide high-level functions so developers don’t need to understand what happens under the hood.

What about more expert developers?

• 11:15 We provide a lot of documentation - we understand that some of our audience are application developers and so don’t care about the details.
• 11:25 But some of the audience are security experts and they need to understand what is going on.
• 11:35 We have different documentation for our products for different audiences.
• 11:40 We have different licenses and allow code changes deep inside for some parts - other parts we don’t allow changing.

What’s the most common cryptographic mistakes developers make?

• 12:15 I have seen so many mistakes in this area.
• 12:25 The big mistake is in not understanding security and cryptography.
• 12:30 Cryptography is just one aspect of data security - it won’t solve everything.
• 12:40 Some developers just believe that as long as the data is encrypted, that they’re fine - but that’s not the case.
• 12:45 There are lot of things, like operation security, access control, and so on.
• 12:55 The first thing is to understand that cryptography isn’t a magic tool to solve everything.
• 13:00 It is a tool that can help you to solve certain cases.
• 13:10 The second mistake is in not defining the data scope.
• 13:15 It’s easy to think about business data, but there are some things that developers often forget like technical data (IP addresses, geolocation data, logs).
• 13:45 Usually no-one deletes logs, and the data can be stored for a long time - but it can also be sensitive.
• 14:00 Regulations like GDPR - some data can fall under that remit should be protected.
• 14:25 So the third mistake in encrypting data at rest is using the wrong encryption mechanism.
• 14:40 A lot of libraries don’t hide the cryptographic choices and still offer [known weak] algorithms like MD5 for hashing.
• 14:55 There a lot of libraries that suggest using old and vulnerable cryptographic algorithms.
• 15:10 Selecting the best cryptographic algorithm needs up-to-date knowledge of the current security algorithms.
• 15:20 Even if the algorithm is selected correctly, there are a number of parameters which are put in that needs to be chosen carefully.
• 16:15 80% of cryptographic issues are caused by libraries misusing cryptographic libraries.
• 16:20 It’s important to understand that even selecting the best algorithms, they can still be misused to defeat security.

What kind of mistakes can you make?

• 17:00 The easiest kind of mistake to make is in using wrong parameters for the cryptographic library.
• 17:10 It’s important to understand that encryption is all about keys, so even if you’re using the right library but using a weak key will break.
• 17:30 Key management is complicated - it’s about how they are generated, where they are stored.
• 18:05 Key revocation is another issue - can they expire or be revoked?
• 18:20 So as an example - Whats App stored backups on Google Cloud that aren’t encrypted.
• 18:50 So the first question I will ask if anyone has backups is whether they encrypt those backups.

What do you recommend with key management?

• 19:15 I think key management is not the responsibility of developers only - ideally a company should have a security team.
• 19:30 It shouldn’t be up to application developers to decide where and how to manage keys.
• 19:45 If it’s your responsibility then there are many key storage providers you can use.
• 20:00 It’s possible to build your own in-house key management.
• 20:10 The best advice is to not hard-code your own key but separate them in different files - and don’t add the key to the source control!
• 20:30 In a perfect world you have some kind of key storage, and every access to that key storage is logged.

What tips would you pass on to others?

• 20:50 I wish I had books like “Serious Cryptography” when I started.
• 21:15 It’s easy to read and has useful examples along with code pieces.
• 21:25 It builds up cryptography from the basics - what’s the difference between random and pseudo random, how to calculate entropy.
• 21:40 It comes to modern cryptography to ciphers and ecliptic curves.
• 22:50 I would also discuss trust about the platforms as well.
• 24:00 If you’re dealing with “Instagram for Kittens” then maybe you don’t need to worry as much.
• 24:10 I would also encourage using SSL as well - but it’s not enough.
• 24:25 SSL pinning is when you check that the certificate that the server provides is the same as the one provided in the application.

What more could be done?

• 25:00 For some people, SSL pinning may be enough.
• 25:41 Some times you need to have mutual authentication in a secure channel between the client and the server.
• 25:15 Sometimes the server won’t recognise the client that is being used - it might be a bot.
• 25:30 So bots can pretend to be using the application’s API but not using the front end - could that be an issue?
• 25:35 Adding SSL pinning, mutual authentication is a huge plus.
• 25:50 Building an extra encryption channel to send super-secret data adds one more layer of protection.
• 26:00 If it is user-specific, we can use some user-generated key based on properties and encrypt the data over SSL.