Developer-friendly cryptography is what I'm going to get started on this morning. How
many of you would call yourselves developers in some capacity? All right. How many of you
work with developers? A couple more. Okay. Very good. So because we have this small screen,
I was kind of moving things around last night to make it larger. But, you know, certainly
feel free to come forward. This link at the top here will get you a copy of the slide
deck in a PDF format. So, you know, if you want to follow along on your laptop or something,
feel free. My name is Bryce Williams. I work for a consulting firm called SysLogic, based
here in Milwaukee, and lead their managed security services team. So my group, we provide
application security guidance and a variety of topics for organizations. We review lots
of code. So we do source code assessments, you know, security assessments on a lot of
different, you know, large systems to small embedded devices. Train thousands of developers.
This takes me all over the place, you know, talking to developers specifically about application
security concerns, which includes cryptography. And personally, I've been in the field for
20 years as an application developer architect, and then transitioning into the security,
the application security space. So everything I do is around application security and working
with the developer community. I want to start with this statement, this quote from Dr. Newman.
And this is, this may be something you've seen before. There's several different variations
of it. This was some, this was a statement that Dr. Newman gave in 2001 for a New York
Times article. And the article was discussing an announcement by a Harvard professor about
a new type of unbreakable encryption technique that he had, you know, put together, he and
his team. And it was based on the use of a key based on a stream of random numbers. So
it's a pretty novel technique. From an academic and theoretic standpoint, it was actually
pretty cool. Where the statement from Dr. Newman and some others that commented on it
was, you know, this is really great, you know, from that perspective, but we often
see weaknesses when it comes to the implementation of, you know, truly great like cryptographic
techniques. So I want you to keep this in mind as I go through this discussion that
you can have great cryptography, but often, you know, putting the pieces together, actually
practically putting it into place is where we see weaknesses. So to get started, I want
to look at cryptographic best practices for 2018. And don't worry if these are unfamiliar
to you or if you can't read it. These are things that, you know, over time, you know,
now that we're in 2018, we have some updated cryptographic best practices. If you were
in Zach Grace's talk yesterday, some of them, there's a little bit of overlap with what
I'm talking about today and what he covered. The best practices, for example, are similar,
you know, derived from the same sources from cryptographic professionals that, you know,
know this topic inside and out. So we have things like random data from kernel-based
CS, ERGs, your random number generators, your crypto random number generators. Use of authenticated
symmetric encryption. Symmetric signatures using HMAC. With your hash functions, make
sure that you're using those that avoid length extension attacks. That's an important one.
Some of this I'll come back to, but just keep in mind, you know, at a high level, these
are the best practices that cryptographic professionals promote and encourage folks
to use. Yeah. So password storage, password-based KDFs, asymmetric encryption, preferring the
use of electrical cryptography or ECC over RSA. For asymmetric signatures, preferring
the use of EDDSA or RFC 6979. And then secure communications, TLS everywhere, you know,
is great. Something along those lines, you know, a good end-to-end encrypted communication
stream, TLS 1.2 or now 1.3. I forgot I had this. So I want to get us started by field
observation. So these are examples I'm going to go through that my team and I initially
reviewed, things that we have, you know, uncovered in our assessments. Some of these, you know,
let's start with a basic... well, hold on. Let's start with some common mistakes first,
then we'll get into the actual examples. So here, some of the things we have observed
include, you know, these different categories. Things like weak password storage. Use of
reversible encryption. This is all too common. AES, RSA used in storage of passwords, not
ideal. Use of hash functions without salts, a little better. Again, not ideal. Insufficient
work factor to prevent brute force. Often, you know, there might be some work factor
utilized or what we call a KDF, a key derivation function, but there hasn't been sufficient
thought put into the work factor. We also see poor key management. Keys are not stored
securely, hard-coded, or placed in source control. It's a pretty common issue. Loose
access control or overshared keys. Lack of granular key usage and periodic rotation.
All sorts of, you know, related key management issues. We also see a general lack of authenticated
encryption. And if you're not familiar with that term, authenticated encryption, don't worry,
most developers aren't either. They haven't even, they've never heard of authenticated encryption.
They don't realize that's something that they need to be concerned about. In their minds, AES,
they've heard of AES, that's good enough. Let's just use AES because we've heard that's military
grade. It's a good start. AES isn't necessarily bad, but you need to know a little bit more than
that. Or they may know they need to use authenticated encryption, so they go down the path
of developing a, you know, authenticated encryption construction based on something. But
it's not the preferred encrypt and MAC approach. We also see use of keys, initialization vectors,
and nonces in a way where there's misuse, there's reuse of keys, they're hard-coded,
they're using some sort of strange obfuscation to, you know, protect them. Use of passwords for
encryption keys. Another big issue, a password is not designed to be an encryption key. You can
turn a password into an encryption key, but a password itself should never be used for an
encryption key. Also weak and or non-random values for these, you know, keys, IVs, and nonces or just
reuse of values. There are certain constructions where reuse of a nonce is a big no-no.
So here's my first example. Use of not encryption is what I call it. So you probably, if you're in
the back, you might not be able to read all of this, but essentially we have, this is in C code,
in fact, all of my code examples are in C. This is from an actual assessment that was performed.
We ran across this function, I think I ran across this one, called encrypt password. And just
skimming through this, right away I knew we had a problem because there's no mention of any
algorithms and any, you know, cryptographic algorithms or ciphers. There's no encryption
key. There's just this interesting line here that's doing some, essentially some, shifting
some bits around. So that's not encryption. That's what we, that's obfuscation essentially.
And you think, well yeah, this is a pretty crazy example. This wouldn't exist that, that often in
the field, or maybe it's super old code. But I think you might be surprised at how often you
run across examples of encryption that looks something like this. In this next example,
we have a random number generator that's being seeded or initialized. Here the comment says it
all. Need to see the RNG with a hash of the MAC address. So if you can kind of read the code here,
it's doing a murmur to hash based off some pieces of a MAC address. And this is just messed up.
You can, you know, a MAC address is a static value for a device. A random number generator,
on the other hand, needs to be, it can't be deterministic. It needs to be unique and
unpredictable. So the use of a MAC address for a random number generator should never happen. It
just, it shouldn't be any part of it. We also see a lot of overly, what I call overly complex
encryption. Just extra layers of things that, you know, you, I remember running across this one for
the first time. You know, right away going, what is going on here? And then breaking down, you know,
reverse engineering the logic to understand what was happening. And it kind of looked like this,
where it's generating a random value. That random value gets stored in a database. The random value
gets split into two. You combine the second half with a plain text, reverse the combined value,
hash it with SHA-256, and on and on. One of my favorite sections is line two here, where it goes
in, creates a UUID, takes the five parts, reorders the parts, and then puts it back together. And
it's like, what, who dreamed this up? And why? And essentially, this second step here is the cause of
the concern. There's actually a weakness in this approach, regardless of the fact that it's just
weird. The random value should never have been stored in the database alongside the encrypted
data. I forgot to mention, this was for storing data in a database using reversible encryption.
They wanted to be able to recover the plain text later. So they use this approach, which, you know,
at its face is crazy. But the reason I think that the designers put this in place is because they
recognize that by storing the random value in the database, it just, maybe it felt wrong. They knew
there was some sort of weakness, so they added additional layers of obfuscation, essentially to
make it more difficult to reverse engineer. Now, obviously, we figured it out. And an attacker with
enough information or access to things could do the same thing. And ultimately, potentially,
reverse engineer and recover the plain text values that are stored in the database. So if they could,
you know, take the entire, or have access to the entire database, they have all the detail they
need to recover the encrypted information. So anytime I see extra layers of complexity involved
in encryption techniques, it usually clues me into the fact that it could warrant some study,
because there's probably a reason there's extra layers there. They're hiding something.
Here's another example. It's not entirely cryptography based, but this is looking at a
system. This is a cloud-hosted, you know, typical web system with a database backend, an API front
end, and a JavaScript UI. Three different issues we kind of highlighted in this particular
implementation. We've got missing authentication on the API endpoint. There is this function called
get to random security questions by user that allowed an anonymous user, so no authentication,
anonymous user could ask this based on a user ID and get back that user's secret, you know,
two of their three secret questions and answers. And then interestingly enough,
when I saw this, I realized we had a big problem. The validation of the answers that were given by
the end user was performed on the client side. So the JavaScript was the one that was actually
saying, oh, did they answer the, did they input the correct answer for this question or not?
Yes or no? So obviously an attacker could bypass that step. And this was a brand new system. I
think we looked at this like two months ago or something. A brand new feature that they added.
So obviously the team wasn't really thinking about the security aspects of this. And even
my third point here was even on the backend, there was issues as well. The answers themselves
to the secret questions were stored in the database using symmetric, you know, reversible
encryption. Ideally you want to store your secret question answers in the same way that you store
passwords using, you know, a key derivation function because there's really no reason to
recover the actual plain text of that answer. You just need it for comparison purposes.
So we looked at a few issues that my team and I have uncovered and kind of highlighted, you know,
some basic issues. So if you compare those to the cryptographic best practices, we're way off
the mark. You know, we're looking at, you know, basic issues that we seem to uncover over and over
rather than, you know, seeing that if developers are able to address the more advanced, you know,
modern topics, they're not there in general. So this slide looks at recent cryptography issues
and in this case these are some items highlighted by Matthew Green, who's a professor at John
Hopkins, pretty well known in the cryptography space. So what did he highlight here? DHUK
FortiGate hardcodes a key that makes every VPN session crackable. You might remember that
scenario. Recently being, you know, in the past two or three years that these issues came out,
you know, in the press. Pretty big deal. All related to cryptography-based mistakes.
Next one, Juniper hardcodes a similar key and then gets hacked by the Chinese, who changed
that key to one of their own choosing. That obviously was a big deal. Every major browser
manufacturer and a number of websites make TLS vulnerable to practical decryption attacks. That
was our freak attack. And similarly the next one, browsers and websites make TLS vulnerable
to practical decryption attacks yet again with the drown attack. Apple uses crypto wrong in
their iMessage encryption for a billion users. That was a pretty big deal. And remember, all of
these are big manufacturers. These are the folks that have big dedicated security teams. They have
FIP certification. So what kind of issues is everyone else running into? Obviously my team and
I have seen some of those and some of the examples that I highlighted. You know, a lot, these are
more complicated kind of concerns, you know, more advanced subtle mistakes that are made. The subtle
mistakes, you know, are going to certainly bound to happen. It's the basic mistakes that we often
see that concern me. So why are mistakes so common? Three different metrics here from different
studies. Just to back up the statement that cryptographic issues are a concern. 61.5% of
applications scanned had one or more cryptographic issues. That's from Veracode's report last year.
But they scan a lot of code obviously. 66% of the most popular cryptocurrency
mobile apps. So there was a study that looked at cryptocurrency mobile apps. 66% of those contained
hard-coded sensitive data including passwords or API keys. I mean that's really unfortunate. And
then look at this last one here. Highlights the fact that 17% of bugs they looked at were in the
cryptographic libraries. Whereas the remaining 83% were in cryptographic, were misuses of
cryptographic libraries. And that last point is what I, you know, want to emphasize that the
cryptographic libraries certainly can have mistakes. And you need to be mindful of those
libraries. And you know, make sure you're using latest ones. And I'll talk more about libraries.
But the implementation of cryptography is more often where we see, you know, problems being
introduced. So if we look at like just a few developer challenges. Again, kind of why are
mistakes made? What is it that the developers have to fight with? I think, you know, for those of us
that do development, this will ring true. Things that you have to, you know, be mindful of as
you're working on a system. You got to make it work. It needs to work first. You have to,
ensure the product actually works before you make it secure. You know, I'd argue that you need to do
both at the same time. But clearly you have to make the product work. That's important. You also
have to meet delivery dates. And often delivery dates can be a priority over adding in a certain
level of security or getting extra expertise or pair of eyes to review it. You might have a
performance or usability concerns as a result of certain security choices. And so maybe they win
out. Performance or usability that is. Might have inadequate security testing. Maybe security
controls don't get tested with sufficient expertise. Lack of crypto knowledge. Developers might not
get the training that they need. The access to knowledge sources to give them the information
about cryptography that's accurate. It might also be a problem with poor library or API support.
Either in crypto libraries that are being utilized or in the programming languages that you're using,
you know, that provide cryptographic APIs. I want to look at those last two items. Training and API
use. Just to highlight a few things. So first off, I looked at the top 10 cryptography courses on
Pluralsight. This is not to dig Pluralsight. They're a beverage sponsor here at CypherCon. You
find this issue with others as well. If you're not familiar with Pluralsight, they're an excellent
online video based training vendor. Lots, you know, thousands of different technical training topics
that you can get. The interesting thing with the cryptography that, so I looked at the top 10. If
you search for cryptography, these are the 10 ones that have, that are focused on cryptography. Some
interesting highlights. They generally provide good history on cryptography and basic concepts,
but generally lack practical engineering guidance. There's no discussion of authenticated encryption.
Remember I mentioned authentication, authenticated encryption, AE, that's a pretty big deal. That's
important. No discussion at all. Also no discussion of secure key management or key storage options.
No mention of kernel based cryptographic random number generators versus user space RNGs. Two of
the courses, two out of ten, made a kind of a passing mention of ECC, but they didn't really
get in any details talking about, you know, why would you want to use ECC versus RSA? What are
some preferred curve choices? That sort of thing. And I think some of it is just because the content
is a little dated in some of them. Not to say this couldn't be addressed, but this is just
indicative of cryptographic, like, training material that's out there. Whether it's stack
overflow posts or, you know, training materials like that. You have to be careful because, I mean,
knowledge is good. But when you give people the wrong knowledge or dated knowledge, it can
actually work against you. And so on so forth. Nearly all hash examples use MD5, which we know
is broken. And quite a bit of odd advice. Things like, you should double your PBKDF2
iterations every year, which I've never seen anywhere else. I don't know where that came from.
Maybe you should use this obscure tiger hashing function instead of SHA-256, because SHA has
been shown to have weaknesses in the past. SHA-1, for example. That's the kind of stuff I don't
want developers to focus on. See, oh, maybe I should maybe I should double my PBKDF2
iterations every year. So now I've got, you know, a gazillion iterations and it doesn't work anymore.
So, what are some popular cryptographic libraries? These are general-purpose cryptographic libraries
that, in my opinion, provide too many options to the the average developer. Botan, Bouncy Castle,
Crypto++, Libgcrypt, OpenSSL, WolfCrypt. This is just a few of them, of course. You may be
familiar with some of these. You may use some of these. It's not that they're bad. They just
provide a lot of different options. Things like, you know, encryption algorithms, hash
functions. And I may not have these numbers, you know, completely accurate. I kind of went
through documentation and tried to summarize things. And it's based on like interfaces and
API endpoints. So, you as a developer go in, you have to choose a hash function. You've got 27
different choices in Libgcrypt. Signature schemes. We're at a reason Bouncy Castle goes
crazy on signature schemes that, you know, at your disposal. So, as a developer, it increases your
chances of choosing something that may not be in your best interest. Oops. Landmines in
cryptographic libraries. So, in addition to having just lots of options, they also have some bad or
insecure options that you need to be aware of. Things like RSA with insecure padding. That's an
area where cryptographers, you know, have a lot to say about. You should never, you know, not
only should you maybe not use RSA, prefer using ECC. If you need to use RSA, make sure you're
using preferred padding. There's a lot of implementations that just provide insecure padding.
That's the default. All of these libraries provide at least the option of using RSA with insecure
padding. AES with ECB mode. We know that's kind of, you know, faulty. Broken ciphers. Things like
RC4, for example. RC2. Just some really outdated, clearly broken ciphers. They're there in every
single one. A lot of it's to provide backwards compatibility or, you know, interoperability with
things. But if that's an option and someone, you know, as a developer, meaning well, maybe they've
copied something off the Internet. I was looking at a blog article just the other day where someone
was talking about old, you know, algorithms that were basically defunct in the mid-90s. Same with
hash functions. Old hash functions. Broken hash functions. This user space RNGs. They all have,
other than WolfCrypt I guess, they all have, you know, this user space RNG concept that can get
you into trouble. Without even realizing it. Because it's just, it's kind of like the default
behavior. Another thing is with implementation challenges. Here's a specific example around the
encrypt and MAC approach. So you have some knowledge. You know you need to use authenticated
encryption. But maybe you're working with a library or a programming language that doesn't
have authenticated encryption. But you can build it yourself with the built-in primitives. So you
put together this encrypt and MAC construction. In order to do it correctly though, you have to
keep all this in mind. You've got to use a different key for your encryption from your
authentication. Preferably you derive those keys from a single master key using a KDF. You have to
also make sure that all your string comparisons use constant time. You can't use standard string
comparison functions. You definitely have to use an HMAC and ensure it includes a ciphertext, your
additional authentication data, the initialization vector, and the encryption method. All of those
have to be packaged inside the HMAC. And those fields passed in the HMAC, they must use a format
that unambiguously delineates them. Any, if you leave out one of those fields, if you don't use a
correct format, you essentially are introducing a weakness. And you don't, you don't necessarily
realize it because this isn't your bread and butter to create these encrypt and MAC
constructions. I've seen so many examples of these where well-meaning developers know they need to
go down this path of authenticated encryption, but they try and put all this together and it's
admittedly, it's complicated. We also have weaknesses in standards and protocols. Many of
you may have worked with the JavaScript object signing and encryption standard suite. It's like a
suite of standards. Things like JSON web signatures, JWS, which even if you have a compliant
implementation, meaning it meets the standard correctly, it is vulnerable to passing in the none
or HS256 algorithms. As an attacker, you can pass those in when you're, when in reality you're
expecting an RSA signature and it's able to kind of work with those. Essentially, it's a fairly
known by now, you know, attack vector. So you want to make sure not only are you using a
standards compliant implementation, but it's also aware of these weaknesses and has put in extra
safeguards to protect against them. Same thing with JSON web encryption, JWE allows this
insecure padding, you know, RSA with insecure padding choice, which is unfortunate. It also
allows ECDH with NIST curves, which introduce risk of invalid curves attacks. A little more rare,
but something to be concerned about. It's unfortunate that these choices exist in the
standard. OAuth 2, you may be familiar with OAuth 2. It's a great, you know, standard for technically
as an authorization protocol, but used in the authentication authorization space. Provides
several weak workflows that ideally should really never be used in modern systems, but I see this
all the time. Use of client credentials and password grant types where they shouldn't, you
know, it's not recommended. There's also this optional state parameter, this in the standard,
it's optional, but it really should always be used. There's also no explicit access token
specification in OAuth 2. So you'll see, you'll see some interesting implementations as a result
of that. There's just no specific guidance. So obviously good implementations of OAuth 2 do a
great job, but they're going above and beyond the standard because they, you know, have
additional knowledge and experience associated with that. I always recommend that anyone that's
working in the OAuth 2 space, that you read the Threat Model and Security Considerations RFC. You
know, if you search for OAuth 2 Threat Model, you'll get this RFC. Goes into a lot of detail
about particular threats and countermeasures that you can be, that you should be aware of. But most
developers just aren't aware of that. And as a result, they don't think about certain types of
attacks you can do in this space. So I ask myself this all the time. Should developers stop using
cryptography? You know, because we do a lot of training. At one point I asked a client and said,
you know, we've done all these assessments. We see all these, you know, consistent issues with
cryptography. Maybe it makes sense to start telling your developers to stop doing cryptography.
Because clearly, at least everything I'm looking at, no one's doing it right. So does that make
sense? Should we tell developers to stop using cryptography? Clearly, you know, one pro of that
approach is to have less security implementation flaws. Con is, of course, then your systems will
lack even basic protections. They're not gonna have use any kind of cryptography. And so then
it's more obvious that you've got, you know, a lack of security protection. So what if security
pros do all the crypto, you know, cryptography work instead? And in certain organizations, that
might make sense. You might be able to do that. But generally, security pros don't scale well. You
can't have, you know, one or two people writing all of this code. You know, anything involving
cryptography, which admittedly is an increasing amount of features and system aspects these days
that need to take advantage of crypto. So that's just gonna slow down progress if you have the,
you know, just folks with specific expertise take care of that. So, assuming we can't do that, what
are some other options? What is this idea of developer-friendly cryptography? Has anyone ever
heard of that concept before? Developer-friendly cryptography? I don't think I dreamed it up. Not
you. So how to define developer-friendly? Here's four different things that, to me, mean it's
developer-friendly. Like, takes it to that next level. There's no need to select ciphers or key
sizes. There is automatic generation of encryption key, initialization vector, salt, and nonce values.
There are simple, clear APIs that provide high-level outcome-based functionality. So rather
than using cryptographic primitives, you know, you have to choose ciphers and algorithms. You
instead say, I, you know, it's high level. I'll show you some examples of what I mean by this. And also
important, also important, there are no insecure or low security options. So as much as possible,
you avoid the scenario where developers shoot themselves in the foot. So, start with, let's look
at some developer-friendly libraries. Those that I feel are kind of candidates for this concept of
developer-friendly. We've got Libsodium. And that's an important one to remember. If you remember
anything from this talk, remember Libsodium. It is a cross-platform, compilable, you know, module
based on the NACL package. It's got language bindings for most languages out there. It's very
popular in the security professional and cryptographer space. It's generally easy to work
with from a developer standpoint. And it supports things like authenticated encryption, digital
signatures, you know, hashing. It's performance optimized. And it doesn't give you so many options
that, I mean, it gives you enough options as a developer to get most things done. If you need
something certainly more advanced or more unique, you may have to move to a more general purpose
library. But this is the type of library that I feel comfortable recommending to any developer in
any sort of environment that they're working in. Libhydrogen is kind of like the younger brother
of Libsodium. Designed for the embedded system space. It's written in C, C99. So it, you know,
it's fairly versatile. It has the same general API, the interfaces as Libsodium. But implemented
with essentially just two cryptographic primitives. So it keeps it very small, very lightweight. Not
as tried and not as well tested as Libsodium at this point. But definitely something that you
should keep your eye on if you're working in the embedded system space. MonoCypher is another one.
Pretty nice and not something I would necessarily recommend over the other two. And then, but at the
same time, if I was assessed, you know, performing an assessment against the system and I saw use of
MonoCypher, Tink, or ASP.NET Core, I would feel more comfortable than a general-purpose library.
Tink is another library put together by some Google engineers that is designed, again, to create those
high-level kind of outcome based functionality. It doesn't have password hashing or performance. It's
not as performance optimized. And it only works with Java and C++. But it's still a decent option.
Even, and then I also want to highlight, you know, ASP.NET Core, which is an interesting one in this
list. And that it is, you know, only a subset of Microsoft's new .NET Core framework. And it, again,
it only provides authenticated encryption and password hashing. And it does provide some key
management functionality as well. But it is, it's kind of nice in that it's built-in. So developers
that can leverage this, I like the direction Microsoft is going with this cryptographic API.
So here's an encryption example from Limbosodium. This is C code again. You don't really have to
read the detail and you probably can't if you're in the back. Other than it is fairly simple. You'll
notice if you, you know, view this later, for example. There's no mention of any cryptographic
algorithms here. No choice of cipher. No key size selected. No, you know, correctly generating
initialization vector or nonce. It kind of makes, I mean, you still have to do, you know, create the
key and create the nonce for the encryption. But it provides functions to do this in a very
simplistic manner. Where a developer is not going to generally choose, you know, a wrong
selection. Here's LibHydrogen. This is a public key signature example. Where again, it's using,
it's creating a public-private key pair and using that to generate a signature to sign some
data and then later verify the signature. So again, very straightforward, very simplistic for a
developer to leverage. So that's all great. But what about FIPS 140? Anyone familiar with FIPS
142? A couple folks. This is, so FIPS stands for the Federal Information Processing Standard. And
publication 140 has to do with this particular space and the two is means it's version two.
That's the current version of FIPS 140. So cryptographic libraries can be FIPS 142 level
one validated. So the software library itself can be level one validated. Level two validation is
reserved for hardware devices. But that validation, that requires some time and money. You actually
have to ship your, you know, your library off to a testing organization called CVMP. They run it
through its paces, you know, look at a whole bunch of things with it. Obviously it takes a lot of
time and you have to pay them. But then you get a certificate that says, okay, we tested this
particular library on this specific set of hardware and actually will list out, you know, whether
it's two or four different hardware-based environments. You know, this particular, like
it's Windows 2008 with this particular version on it. So they certify that will work properly
according to FIPS approved standards with that particular environment. Use of FIPS validated
modules is mandatory by US and Canadian government agencies. Others may use it as well. But
definitely if you're working in the federal government space, this is most likely going to
come up for them. It's important that you have a FIPS validated library that you're utilizing.
It doesn't mean you have to create one and get it validated. It just means that any of your
cryptographic choices, you know, your cryptographic code is utilizing a library that's gotten this
sort of validation. Keep in mind that FIPS validation doesn't necessarily mean that it's
more secure. That that library is more secure. It just means it's gone through this validation
process. It's been reviewed essentially by the CBMP against FIPS standards. So if you are
working this space, you do need a FIPS validated library. But clearly you can't use any of the,
well I shouldn't say clearly because I didn't state it, but any of those libraries we looked
at before, LibSodium, LibHydrogen, none of those are FIPS validated libraries. And there's reasons
for that. They, you know, they're really not in a position where that they want, they need to
pursue, you know, as an open source library to pursue this validation. Generally you're looking
at a commercial library that's gone through this process in this case. So they're out there.
There's some good libraries like WolfCrypt for example, NanoCrypt by Mocana. Even OpenSSL has a
FIPS validated version of the library that you could look at. I do recommend that if you need
one of these, that you take the time to consider writing a developer-friendly wrapper around it.
Similar to, you know, providing interfaces similar to LibSodium or others. Or maybe get some
expertise, some outside help for example, to put this together, this wrapper for your developer
group. That way they're not having to worry about the specific cryptographic choices and so on.
Also, key management best practices. We talked a little bit obviously about, you know, general
encryption and cryptographic function best practices. Key management is another area that I
mentioned is a fairly big weakness. Developers in code that I've reviewed and my team
has reviewed, they can at times do a very good job of putting together cryptographic functions.
But then the keys are, you know, they're stored in source control or they're stored even in, you know,
hard-coded in the system itself. So, some best practices around key management. If we had an
ideal system, it would have all of these. No key or secret should be stored in clear text. Keys
should have a defined limited lifetime based on usage. The keys should be refreshed automatically
where possible. There should be a method to manually revoke keys. You always want a way that,
you know, once you generate a key that you can revoke it. Even if it's, you know, kind of a
manual process that you have to go through. Keys should never have an unlimited lifetime. Access
to clear text keys should be limited through authorization or permission. So, being able to
play some access control around it would be, is important. You also want to make sure that access
to clear text keys is limited through authorization and permissions. And the all key lifecycle and
access events should be audited. So, ideally, anytime there's, you know, access to a key, you
know, you pull it out of a vault, for example, that there's a log event that occurs, you know, this
particular application or this particular user. You see this a lot with code signing. You know,
if you've got an implemented code signing kind of process set up within your organization, you
generally want to have a more robust handling of the key material around use of code signing. So,
only certain individuals have access to that. That usage is fully audited and so on. It sounds
like we're in an elevator. So, some key management solutions. You might not be able to read this
slide, but I'll highlight a few solutions that are, you know, some pre-made kind of solutions
rather than having to roll your own, which is generally not ideal. So, you've got HashiCorp
Vault or KeyWiz. These are good for distributed systems, you know, client-server environments,
anywhere where you've got more, you know, more components involved in your particular system
environment. Vault is considered the gold standard in this space. They have very comprehensive key
management strategy and allow a variety of topologies in how you deploy your key management
infrastructure and so on. So, it's a great tool in this space. You may also leverage a hardware
security module. And hardware security modules often can be used with a lot of these solutions
as a hardware backing, essentially. So, you could get it in a chipset form if you're working, you
know, an embedded environment, for example, a bedding system. Maybe as a USB device or even as
like a rack mount appliance that you could have in your own data center. An HSM provides a very
protected form of kind of a vault, if you will, you know, an actual hardware vault to store keys.
And to do so in a way where it's tamper resistant, very difficult for someone to pull keys out of
there. They actually get generated on that device. And those keys, at least, you know, in case of
private keys, for example, they never leave that device. They always stay there. If you're working
in the cloud, you got things like Amazon KMS, Azure Key Vault, Google Cloud KMS, and OpenStacks
Barbican. These are all HSM as a service, essentially, which are great, especially if you
need to use this on a maybe you need to use an HSM on a more periodic basis. You don't have the funds
to get a full HSM appliance. You can just leverage one of these systems and do so in a fairly
inexpensive manner with good, you know, robust. I mean, on the back end, they're essentially using
those HSM appliances themselves. If you're working with either Ansible or Chef in automation
processes, both Ansible and there's an Ansible vault feature and Chef has a vault feature as
well, which is above and beyond just Chef data bags. Chef vault is more robust for use with
secrets and key management. They do lack more advanced features like, so for example, if you're
using Ansible vault, you're not going to get all the feature set that you would with HashiCorp
vault. But because it's built in, it can be obviously very convenient. It's a good place to
start. If you want integrated secret and workflow management, you might want to consider Docker
with SwarmKit or DCOS. They have commercial offerings of these that offer even more advanced
features then, but you will get some, you know, a basic feature set in the free versions, which is
a good, again, not as robust as like a vault implementation, but that integration, of course, is
nice. The other ones I'll mention, Knox, Tink, and ASP.NET Core. Those are all examples of
integrated application level key management. You're not going to get necessarily the more
advanced features, but they, and they have more limited language bindings. For example, obviously
ASP.NET Core only works with ASP.NET Core. Tink only Java and C++. I forgot now what Knox works
with. Probably Go. But they're very, they, because you can implement them at your application
level, you've got more flexibility on how those keys are managed. Often, they will also work with
an HSM backend. So if it's present, you know, you can leverage the HSM hardware. So high-level
developer-friendly recommendations. Transport layer security. So if someone, you know, if we're
reviewing code or someone comes to me and asks about what kind of algorithms should I use for
secure communications? I say, let's not talk algorithms. That's just, you know, we're, we're
gonna go nowhere with this. Someone's already done that work for you. Just use TLS or essentially,
you know, a robust communications protocol that is already gonna take into consideration all the
things that you don't need to worry about. And do so in a, you know, in a right way. In a secure
way. On the storage side, you want to consider built-in storage encryption solutions where
possible. You know, certainly take advantage of these if you have the opportunity to. Things like
Microsoft's transparent data encryption. Again, you're just getting disk level encryption at this
point. But it's so easy to use, there's almost no reason why not to. And it gives you the ability
to protect your data at rest, your data backup, database backups and SQL Server and so on. Same
thing with like Amazon's EBS encryption, full disk encryption. Those are just good options to
leverage where you as a developer don't have to do anything. You don't have to know it even exists.
It just kind of works for you for those, for specific scenarios. We mentioned developer-friendly
libraries. Definitely want to check out use of those libraries, even above and beyond, you know,
your built-in programming APIs. For example, in .NET. .NET has a pretty decent cryptographic API
that includes, that is included with the framework. But I've seen so many misuses of it. The general,
my general recommendation to development teams as we go through training is, wherever possible,
use Libsodium. If you need to get, if you need to get to the point where you need to use
cryptography, you need to use some encryption, like you can't leverage TLS, so you can't, you
know, it's, it's not covered by any of those kind of built-in solutions. Take advantage of Libsodium,
which has a, you know, Libsodium net is the .NET language binding of Libsodium. And then key
management solutions. You always want to consider how the keys are being managed. That includes,
not only, you know, your production environment, but also your test environments, your local
development. Anytime I see a key checked into source control that is not specific to a development
environment or, you know, kind of a small test environment, we always want to flag that and say,
hey, this is not an ideal solution. Oversharing of keys is all too common and very easy for things
to leak out. I mean, we've probably all seen examples of things that get into GitHub or get
into areas where they're just more accessible. Logs, sometimes, a lot of times keys get logged
too. And those logs will get aggregated into log management systems. And those logs, you know, or,
you know, sucked in via syslog systems. And so then you've got more people with access to your
logs. And then if they get keys or credentials that way, then you've opened up a door and so
on. Questions? I left a little time here. So any specific questions? Yeah, feel free. These links
are, again, linked to the slide deck. And I specifically put in three links because I wanted
to keep these, these three tools, if you will, or libraries, is what I would consider the most
important. These are the, these have a general purpose in the sense they have broad applicability,
broad, you know, usage in the case of Libsodium and Libhydrogen. Fairly decent, like, language
binding so that they'll work in most scenarios. So if you're working in PHP, in fact, PHP has,
default cryptographic library now, which is pretty exciting. They're, they're kind of ahead
of the game, of all things PHP. Well, if you're working in Ruby, Go, Rust, .NET, Java, you name it.
I probably have, there's probably a Libsodium binding for you. Questions? Yes? Are there good
code review options for cryptography specifically? Yeah. My team, obviously, enjoys looking at
cryptography. There are other, I think, firms that kind of specialize in looking at cryptography. But
from an automated standpoint, there are some things. I think most tools, I, I have a leg in
the like static analysis space as well. And spend time looking at what tools are capable of in
determining cryptographic issues. And it is an interesting space. Clearly they can identify
usages of old, outdated functions. But being able to determine if you're using even newer
functions in a proper manner, can be complicated. You know, you got a, like an encrypt and max
solution. It might be great. It might be that you've missed something and it's just, there's
just not enough context for an automated tool to figure that out. So I can't point to one specific
example. I think most, obviously the big-name commercial static analysis tools are probably,
all attempt to do something in this space. Lighter weight tools, you know, open source tools, varying,
it's mixed, I think, based on the language. Java has some very interesting default cryptographic
choices. Things like, if you encrypt with AES, you're gonna get ECB mode by default. So that's
obviously not cool. So a lot of tools will pick that up. Some Java based concerns. So yeah. Cool.
All right. I think we're good. Thanks, everyone.