The Digital Trust Journey: From Key Generation to Signed Certificate - Carl Mehner

all right well good morning besides I am extremely excited to be here again speaking at bsides San Antonio uh always a very great conference lots of diversity in everybody that's here and everybody's always hungry to learn so I'm really really excited to teach youall about certificates today so how to make a certificate that's what this talk is about and the good news is it's extremely simple there's basically just three steps first you make a private key you make a CSR and you get a certificate authority to assign it and that's that's pretty much it any questions can you expand a little bit on what happens in steps one and two okay expand a little bit on steps one and

two yeah I can I can do that so I realized this about like trying to teach you how to draw an L like this so maybe we need to get a little bit further in the weeds so certificates are basically just a way to cryptographically bind an identity to a cryptographic key so you take uh an ID a key and you bind them together the ID can be anything from an email address a website uh a person's Company ID a service account that's exec uting some type of workload in a system or even a a set of permissions on a cloud API using something called spiffy which is uh one of the newer protocols for for running

workload with certificates certificates help us all the time in our digital interactions so you probably used one this morning as you pulled up the QR code to Reg to get into the registration here today your email was going into uh TLS and using the certificates for

that but how do we trust this uh The Binding between the certificate and the key well that's what certificate authorities are for so certificate authorities they are uh embedded into browsers and operating systems and they're the root of trust for this binding of the ID to the key uh certificate authorities have a very specific set of rules that they have to follow and those are all laid down by The trustor Operators that manage all of the certificate authorities that are embedded inside of your browser and operating system and all of the ca because of those rules they have to follow they're audited and they're held to a very high standard to make sure that they

following all of these rules there's a there's a whole document that's put together and managed through something called the ca browser forum and it's a a place where certificate authorities and the trust store operators can get together and work on how to agree on when to move the different rules and regulations forward and agree on when everybody has to participate and be hold to those set of rules and it includes things like how the certificate Authority would validate the ID that's in there how it has to keep certain operational or uptime requirements and everything that it has to put into the certificate itself but there's a whole lot more behind what goes into a certificate than

most people see there's a whole ecosystem behind the certificate Authority that's aused from not only the people using certificates in the browsers and connecting to things over the internet but it's also kind of obvious getting from the people that are giving the certificates running websites who here has ever put a certificate on a website either for work or personal lots of people in here there's a whole lot more that you probably haven't really been involved with behind the scenes getting a certificate Authority especially a a public certificate authority to get everything that it needs to put everything into the certificates themselves so welcome to the in the weed track and we're going to dive down and get all the

way down to the the root of certificates so to start we're going to need a private key right now there's Just Two Types you have elliptic curve digital signature algorithm and an RSA key and those are the only two that are allowed out on the public web right now to to be signed by these trusted certificate authorities now RSA is the easiest to explain it's just two big prime numbers ecdsa is based on elliptic curve cryptography and it is way way harder to explain but making the private key is way easier all you need is a big random number and that's your private key for an elliptic curve so elliptic curves are basically just uh lines on a graph but because

computers are finite and you only have so much room in a computer register they kind of wrap themselves around the graph and you have to have discrete points but like I said it's way harder to explain those than uh just multiplying two primes together it's a whole another talk in of itself so the goal we had to bind an identity to a key and we got our key now right so we bind these two together and share it to the world but this is private so we can't do that luckily there's another part to this which is the public key so all the keys that are in certificates are something called asymmetric Keys there's a private

half and a public half so now we need to get the public half that we can actually use for sharing out to the world so with RSA still pretty simple you just multiply those two prime numbers together and you get a big number and the whole security of RSA is based on the fact that it's really really hard to go from that that multiplied number back to one of those two prime numbers and people have been trying to come up with easier ways to do this for thousands of years it goes all the way back to uclid and continued all the way up through the modern day of trying to find a a good easy way to reverse that RSA function

that we rely on to keep our stuff secure uh for elliptic curves uh we don't have anything in the private key to multiply but we have a really big random number and all you do is you take a point on that grid of dots and you start adding it to itself as many times as that Prime that random number is and the public key for an elliptic curve SE is just an XY coordinate on that graph so now that we have our keys we're going to bind it to the ID using something called a CSR so in order to get the requests to the certificate authority to sign we need to create this thing called

a certificate signing request and it's just a document that has an ID it's got the key and it can have some some usage request in it so the ca doesn't have to abide by these requests because like I said it's got a very specific step set of steps that it has to follow a really strict rubric that it has to maintain so can only include things that fall in line with the profiles that it's set up on the ca side the usage it's uh anything that is any type of special privilege or or a use for the key so things like encrypting signing creating digital signatures uh being used for TLS or for authentication to a

system things like that so the last part of the ca uh the CSR is a temporary binding so this isn't a trusted binding but it is cryptographically strong and it just shows that the machine that generated the private key is the the one that created the CSR now now it's ready you can send it to the certificate Authority and this is where uh the certificate Authority takes over and tries to send it off and create the the certificate for it and to quote Skywalker this is where the fund begins before the ca signs assert it has to create what is known as a TBS certificate that stands for to be signed so it's a template that the certificate

Authority fills out in order to get all the information that it needs to have in the final certificate in order for it to be useful and trusted for everybody outside so it looks at what's in the CSR vets it and if it matches all the verification rules it'll copy it over into the TBS certificate so the first thing the ca needs to do is see if it's even allowed to issue a binding for this particular ID so what it does is it'll reach out in the DNS and use something called a CAA record or certificate Authority authorization record if you want to hear more about that you can go to Paul's talk later today and he'll talk all

about it 2:00 right there at 2:00 so with CA uh you just check the DNS to see if the ca is allowed to issue it looks at the special DNS record sees if the certificate Authority's name is in there if it is that CA can issue the cert if it's not the ca is not allowed to issue the CT and has to stop right there if it doesn't find anything the DNS that's basically implicit permission to go ahead and sign it what if it ignes the C record if it ignores the CIAA record and it doesn't follow what it says and maybe it says somebody else's name in there then the C can get in really big trouble and get

pulled out of all those root stores and then all the certificates that were signed by it aren't trusted anymore and that's bad because it breaks things so the the requirement for website Sears for CA has been in place for a couple years but in March of next year it's going to be in place for email certificates as well so if you're issuing email searchs in the public internet CA records can help prevent other certificate authorities that you're not expecting from issuing Sears for your domain so the next thing is arguably one of the more important things here the ca has to check the ID that it's going to bind in the CER certificate so to do

that um it has to see if the person or machine that's requesting the certificate is authorized to get a certificate for that identity so one of the ways to do that uh especially for email certificates is to send a code to an email and if the person has control over that email address they can get the special code hand it back to the certificate Authority and it'll verify that that person has control over the email which proves that it can have the search for that email address for website Sears you have to prove ownership of whatever domain names that you put into the CSR and there's only a couple ways to do this one of

them is just like for email accounts you can send a special code to one of the emails that is considered authoritative for the domain so if you have a domain like mine C m.me they would send an email to administrator or hostmaster or postmaster things like that and if you can get an email sent to you for those email addresses on a particular domain you can get a certificate for that

domain so the ca checks the email it could also check a website URL so you can also instead of getting the code in email and reflecting that back to the ca you can get the special code and just put it up onto a URL that the ca will then go and check and see if the secret code is there and if you can that'll prove ownership over that domain another way to do it is to put that code into a DNS record and so the co then can go out and check the DNS to see if the code's there and see if you can if you're authoritative to be able to issue aert for that

domain excuse me so once the ID is verified the casa will sometimes adjust that ID and add things like a a state or an organization name sometimes a physical address like a mailing address and once they've verified all that they will copy it over from the CSR into the TBS certificate so the main name goes up on the top and any additional names go uh down into the the bottom into an extension we'll talk a little bit more about those later so not only does the ca need to verify the identity it also needs to verify the next part the key it has to make sure that the keys algorithm and key strength is safe enough and strong

enough for use on the internet so for example you can have a 4096-bit RSA key which is really strong but you can have a 1024-bit RSA key you can use one of the elliptic curves that mist has defined p256 but you can't use one of the newer arguably more secure curves x25519 once the C has checked if the key is uh strong enough and and meets all the requirements it also has to check if the key has already been known to be compromised so that's another Reach Out that the ca has to do it will go and check out a list of all the known keys that have been compromised at least the ones that have been reported to that

certificate Authority so it has to maintain a database of anything that it's ever been notified of that's compromised anything that it's marked is revoked beyond that so that's actually per ca for for this one the ca is only responsible for checking the searchs that it particularly knows that's compromised so there's at least not yet there's nothing that uh you can go in query somebody else's certificate authority to see if you've got one of their compromise Keys however there was a vulnerability back in 2008 in Debian that the random number generator was really really good at creating really really weak keys and those keys proliferated all over the internet and the the operating system that had

that weak random number generator kept getting included into appliances both virtual and physical appliances that companies would run on the edge of their Network so that they were exposed to the public internet and it used all of those weak keys and unfortunately even a month or two ago somebody released some research where they found a whole another slew of these Keys being used in production live signing email so all of that was being used for Demar now typically Demar Keys it's a email security standard they don't relate to certificates so none of the certificate authorities caught this but out there on the public internet signing email we have all these weak keys that had been

generated by this random number generator from 2008 well the vulnerability was made known in 08 so C have to do their part to make sure they're trying to keep weak keys off the internet and for Server Sears the certificate Authority is not allowed to generate the private key so one of the other checks it has to do is to make sure that it has never generated the private key that's associated to the public key in the CSR so it has to go and call out to another list where it's got a list of all the private Keys it's generated you can ask the ca to generate a private key for an email CT at least

for now and download the whole package with the private key and the certificate itself into your email client but not so with web Sears so CA has to check all that if it doesn't find the private key into the database then it's done checking the keys and it can take that key from the CSR and slide it over into the TBS certificate next up is the usage from the CSR so this is probably the uh the thing that needs the least amount of checks because it really depends on what profile the requestor asks the ca to put the CT under is it a web CT is it an email CT is it a code signing CT the ca

takes whatever usage the CT's intended for and copies that over into the usage part of the to be signed certificate there's a couple Fields here in the certificate that really remain the same for pretty much every certificate or at least every certificate that's issued by a particular CA so one of those is the version number so this is the version of the certificate standard it's been number three for a really long time 20 30 years the issuer is just the certificate Authority's name the name of the the actual CA that's issuing this certificate the algorithm that the certificate Authority is going to sign this certificate with things like RSA with sha 256 or ecdsa with sha

256 it'll put that up here so that uh the clients know what to expect whenever they're validating the signature later on the next up is the serial number so each certificate has an individually printed serial number on it that has to be unique for a given SE CA so two different Casa theoretically could issue the same serial number but it's a requirement that the ca check that any certificates that it issues have unique serial numbers and that's important because a serial number is used to revoke the certificate so if you have two CTS that have the same serial you revoke one it ends up revoking both of them there's a couple other requirements in here the serial number has to have at

least 64 bits of Randomness in it a couple C have gotten in trouble by having like 63 bits of Randomness and then they have to go and revoke all the asserts that didn't meet those requirements so after the lookup to make sure that the serial number is unique the ca will put the serial number into that framework for the TBS certificate next up is the validity period so each certificate has a start date an end date the start date is required to be within 48 Hours of the actual signing of the key so normally CA will put that to the closest midnight whatever midnight GMT whatever's closest they'll just toss the the start data of

the sech there some other certificate authorities will just put it as the the current now Tim stamp it just depends on what software you're using for the CA and what you've configured on it but we do a 48h hour clock skew uh or 48 hour allowance on either side of the actual signing date in order to allow certificates to potentially back date or forward date slightly that CSR or the the final certificate so that if you have a computer that's got a slow clock or if you've got a computer with a fast clock whenever you deploy that CT out hopefully using automation any clients that hit it right after it gets deployed won't have a problem validating it

because if a client hits aert and it says yeah I'm not good until tomorrow then you can't trust it and it's going to break that client's connection so if you know that you have a bunch of clients that possibly could have some clock skew you can adjust your uh start date that way now the end date is right now restricted to a maximum of 398 days so that's about a year and 3 months and mostly that's just for kind of Legacy reason where C would give people 3 months ahead of time to go and try to renew their certificate so they could get a year out of use out of it but some CA will issue

searchs down to seven or 10 uh up to 90 days but they could also issue it for any number of days in between as long as it doesn't go past that 398 so after that the CAA starts to populate all the rest of the fields here it adds information on where to find the ca's certificate so sometimes browsers if the server is misconfigured the browser can call out and grab the ca signing certificate to see if it's one that should be trusted take some extra round hops it's not very efficient but it's one thing that the browsers did to help server operators stop shooting themselves in the foot and breaking clients it'll also add uh revocation

information so this is how to tell if the searchs are Ved usually this is a URL that the again the web client can hit and say is this one of the revoked ones or is it good can I keep going uh it'll also have a place in there for policy information this so this is where the ca says I issued this sht in accordance with this policy and it's got another URL that'll go out to the certificate Authority where it's listed what policy the CT was issued under now most of that was relatively the same for every certificate that the the ca's issued uh at least for a given certificate Authority Under a specific profile but we have one more in here

this is the newest uh extension that CA are issuing with it's called the C sign certificate timestamp list and sometimes it's referred to just kind of as a concept and whole as certificate transparency or CT so CT was started as a concept by some Google researchers back in 2011 through 2012 they released a paper on it to say hey we have this great idea it was in response to a certificate Authority breach where an attacker got into a certificate Authority and started issuing certificates for google.com and nobody knew about it until somebody posted on a forum hey I was looking at my sht because I like to look at Sears and I saw that this was

issued by this weird certificate Authority in the Netherlands what's up Google and Google was like um that shouldn't be happening we need to find a way to stop this or at least know about it in the future so they've been running with chrome uh for about a decade now the certificate transparency was codified as a internet draft standard back in 2013 in 2015 Chrome started mandating that some certificate authorities used it because they were maybe misbehaving a little bit and issuing things that they shouldn't so Chrome wanted to make sure that they knew what was going on they added some more Sears in mid 2016 and then by 2018 chome started mandating that every public certificate for web

included this certificate transparency extension but this extension that goes into the certificate it's only a really small piece of the entire certificate transparency ecosystem overall certificate transparency is just the idea that every CT has to be logged into a public distributed database multiple public databases that hopefully are managed by different groups of people in order to help prevent collusion and to to maintain the Integrity of this distributed database the databases are made of special structures that are appended only they're signed and they include a Tim stamp in every entry that shows exactly when that certificate was [Music] logged so these blocks whenever you add it uh the certificate will hash will get hashed that hash gets added up to the

tree head and then the tree gets signed up at the top of the head so it's basically an aggregate of hashes that go up into the top of this certificate transparency tree so whenever you add another certificate it becomes another Leaf into this tree those two leaves are hashed together and then that hash is hashed into the head and it's signed again if you need to add another certificate well you you've ran out of room on this node because you can need you can only have two nodes per or two Leafs per node so you just create another node there to add a certificate to everything hashes up and then the sign tree head gets moved up to the top

of the tree

structure so if the if the node isn't if the node that's getting a certificate added to it isn't at the top of the tree structure uh you just simply add another one and then this tree starts building out it grows bigger and bigger and bigger lots and lots of cryptographic operations that are necessary for all of this to take place hashing for every leaf every node up the root up to the root and then assigning operation to cap it all off to make sure that everything is trusted but if you have a lot of certificate authorities submitting to a log or a group of logs that can be a lot of cryptographic operations and you can start getting a

backlog of things that you need to add to the queue so to help with this the the logs came up with something known as a maximum merge delay so that's the amount of time that the log has to include everything in its backlog into this tree structure to make sure that everything is included and that it gets all of the hashes and and signatures done in a specific amount of time the problem is that maximum Mar delay is usually a lot longer than a certificate Authority is willing to wait because if I've automated my certificate issuance and I'm trying to get aert from a certificate Authority I want that as fast as possible and the

ca's already got a whole bunch of other steps that it has to do so we wanted the logs to be as fast as possible as well so there's a concept to Sol this called a sign certificate timestamp this basically a receipt from the log saying I've got it I promise I'm going to include this in the log it'll be within the maximum merge delay but in the meanwhile here's a receipt that you can take back to the certificate Authority and it's tant amount to a promise to include the certificate in the logs at a later date before the maximum merage delay

so there's lots of groups that have a vested interest in making sure that all these SS are logged uh but browsers have been the ones been pushing the most for it and and really have the most sway because they have a say in what certificate authorities get included into the trust store so they've been the ones pushing for this and like I said from 2018 all of the public CTS have had this in it since then software's been catching up and you can can see the decoded scts now and and things like Windows and I think Mac OS also has a a decoder that shows a little bit prer uh version of what's inside all that's in an SAT is

the log ID the timestamp and a signature and before oops so before uh they added this into the browsers for the certificate viewer all you saw was a whole bunch of hex numbers that didn't make any sense to most people so CT gets sent off to the ca but in order to sign the certificate the ca has to have that embedded into the certificate but it can't get the SAT until it logs the certificate and it can't log the certificate until the search signed and it has an but it can't get the so there's a catch22 there's a cycle here that we we have to find a way to break so the solution for that is to

create a construct known as a pre- certificate a pre- certificate is exactly the same as the final certificate for every single field except for the certificate transparency extension and in that they put basically a they call it a poison extension it's something that says this certificate cannot be used for anything else other than for logging a certificate to a certificate transparency log so you can't use it for creating a trusted site for a browser can't use it for signing email this is only good for logging and the reason is the reason for the poison extension in there is the signature that goes on the bottom of the CT is signed with the same private key

that will eventually sign that final certificate so back to the highle overview we've got the ca sends the pre- certificate over to the search transparency logs the search transparency logs send back an SAT and the ca can embed that into the extension what happens if the private key for that log gets compromised the browsers have to untrust that log and they're relying on the logs to be trusted so that they can validate the CT so if we untrust a log every certificate with one of those scts in it is now untrusted because thect is no longer trusted if I've got the private key for a log I can start signing scts at will I don't even have to abide by

the current timestamp I could backdate every single Tim stamp and make it look like I've logged the CT so that the browsers and the website operators everybody that's looking over at this transparency ecosystem that's reading these public databases they wouldn't know looking at a particular CT that it was not trusted and so it's effectively gone back to the same problem that Google was trying to solve originally I can now issue Sears that aren't really logged but it looks like they are so how do we solve that well simply we just add more logs so the ca then instead of just going to One log it'll go to two or three it's depends on the time that the certificate's valid for so

if you have a CT that's valid for six months you only need two SATs if you've got a CT that's valid for an entire year you'll need

three so here from the beginning I send the CSR to the certific Authority the ca checks in DNS if it can issue the CT it goes back and checks in either DNS or email or on the website if I'm allowed to have that CT it'll go and check the key that I requested to be in the certificate to see if it's valid to see if it's uh a good key or if it's compromised it'll see if the ca has ever issued that key and created the private key for that public key that's in the CSR it'll create a serial number and it'll go and check its list of serial numbers to see if it's ever issued that

serial number before and then it'll create a pre- certificate sign it and send it off to multiple logs getting back multiple scts embed all of those into the final certificate the final TBS certificate and then finally it'll hash that TBS certificate structure send that hash to the ca's private key the ca will sign the private key or sign the hash with its private key and then you have a certificate thank

you we do have I think about five minutes for questions so if anybody's got those yes

sir for the compliance for all that saying stand okay so the question was what standards does the certificate authorities have to abide by who enforces it where does all of that come from so there's a thing called the certificate Authority browser forum and it's a group of people that issue Cs and people that look at Sears and see if they're trustworthy that body agrees on the set of rules that they want to publish but it's it's ultimately up to the individual trust store operators to have specific rules for the certificates that are included in their trust store so Microsoft's got a whole group of people that work on what trusted means for Microsoft mozilla's got a very open

Community with different people in it that make the rules specifically for Mozilla Chrome's got a similar thing Apple's got a similar thing uh there's other trust operators that kind of abdicate a lot of that responsibility to miss because it's really the most open they have public forum public discussion Microsoft's basically the opposite of that they're very closed you hardly ever hear from them but it's that group the ca browser forum.org is the website they have a set of Baseline requirements and that's what most of the certificates uh are issued off of profiles on there can you explain uh how you're detect or how it's detect certificate transparency private key is compromised and also how is it I really

follow so the question was about how to know if a certificate transparency log private key is compromised so one of the ways to do that is if somebody publishes on GitHub that's probably the easiest uh another way is if somebody finds a certificate that has anct in it that's not in the log that it says it's from so that could happen multiple ways it could have gotten into the queue after it had gotten the issued so got it into the inclusion queue supposed to have been logged but the server rebooted and lost all its memory and so it never got logged it could also be that the private key is compromised but it doesn't really

matter which scenario that is because both of those scenarios are grounds removal of that log from the trust store and from The Trusted set of logs that the browser has so it's less important if the private key is compromised or if the log is just misbehaving or had a really really bad day which several logs have had so whenever that happens you look at the the certificate and as long as there's still one of those SATs that is trusted the browser can still trust the certificate that's why they include three of of them so at least one of them has to be trusted whenever they're evaluating the trust but there have been casions where all of the scts that are in assert have

gotten untrusted and when that happens the cert is untrusted and the ca has to notify everybody that's got a certificate there and get them to reissue the CT and reapply it to their [Music] website any more all right well I thank you for uh coming to bides and thanks for attending the talk appreciate it