深圳风采开奖走势图:Anastasiia Voitova on Cryptography and the Design of Cryptographic Libraries
深圳风采开奖号码 www.ljvch.cn In this podcast Wes Reisz is talking to Anastasiia Voitova, known as @vixentael in the security communities who works as a Product Engineer in Cossack Labs. She started her career as a mobile application developer, and in recent years has moved to focus mainly on designing and developing cryptographics software. We’re going to talk about cryptography, how to design libraries to be usable by developers, and designing cryptographic libraries. We’ll also discuss about her talk from the recent QCon New York , called “Making Security Usable”.
- Choosing a good encryption algorithm isn’t enough - the parameters need to be chosen carefully as well
- Algorithms like MD5 should not be used for hashing any more
- Security is not just the encryption layer - it is the design of the whole system
- Backups should be encrypted as well
- Logs may contain sensitive GDPR data and need to be processed accordingly
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.
QCon is a practitioner-driven conference designed for technical team leads, architects, and project managers who influence software innovation in their teams. QCon takes place 7 times per year in London, New York, San Francisco, Sao Paolo, Beijing & Shanghai. QCon San Francisco is at its 12th Edition and will take place Nov 5-9, 2018. 140+ expert practitioner speakers, 1300+ attendees and 18 tracks will cover topics driving the evolution of software development today. Visit to qconsf.com get more details.
More about our podcasts
You can keep up-to-date with the podcasts via our RSS feed, and they are available via SoundCloud and iTunes. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.