 Yes, development team doing some needs stuff. Cool. Well, thank you, everybody. Great to be here with you. I know it's a shame that so many people were not here, but at least we're here and thankful for that. My name is Bruce Momjin. I live in the United States. I am one of the Postgres core team members, and I work for Enterprise DB. As part of my work for the database about nine months ago, I decided to do some research to understand cryptography from the mathematics all the way up to the implementation. And you're looking at one of four presentations that came out of that research. The slides that you're looking at today are actually at this website right here. If you just put my name as crudely as you can in the search bar, it will come and it will find my website. There are four security presentations under the Presentations tab. And there are also 20 or 30 other presentations related to Postgres, including recordings of those presentations. So again, I hope you enjoyed it. We have about a half an hour, and I am excited to be giving this for the first time, brand new presentation, and very exciting. So what are we going to talk about today? It looks like a lot of information for 30 minutes, but we're going to do our best. I do have some presentations on my website to talk about cryptographic fundamentals, cryptographic communication, cryptographic hardware installation, and configuration. And this is the final talk, which basically talks about applying cryptographic hardware to actual problem domains that you have. The previous presentations, again, cover things like TLS, AES, public key cryptography, RSA, Diffie-Hillman, elliptical curve, elliptic curve, and also the complexities of configuring things like a UB key. If you're familiar with that device, I actually happen to have one with me, which you probably won't see because it's so small that you will probably have trouble. But it effectively is stuck in my USB thing here. Yes, it is this huge device. And I have unplugged my thing. And I will re-plug it in. As soon as the blue light comes on, there we go. There we go. It should come back. Yes, there we go. There we go. Thank you. So this is actually a UB key right there, that little. If I can hold it, yes. That is it. It fills the slot, is about all you can say about it. But effectively, it is a way of cryptographically storing secret keys that can only be accessed through the hardware. So unfortunately, I don't have time to talk about that because 30 minutes is not going to allow me to do that. But the point is, and again, feel free to look at my website to get the details. But the point is that normally when you're doing something cryptographic, you have to store the secret on the same computer that you're using. And obviously, if anyone gets access to that computer, they can copy that key off and do all sorts of things with it. The creative thing about the UB key in all of the hardware specific devices is that the key is only inside the device. It never leaves it. It can't be copied out of the device. I think that's the key point. So that unless somebody steals the physical key, there's no way of copying it in a way that's undetectable. And I think that's the real win. But what I'd like to talk about today is effectively how to use hardware cryptography for specific applications. We're going to talk about open SSH. Then we're going to talk about PGP, depending on how you want to say it. And then we'll talk about Postgres as a conclusion. So again, as I said, the UB key, which we're not going to cover unfortunately today, is actually a hardware device that sits in your USB socket. And there's a whole bunch of configuration that you can use to basically set up that UB key. For those of you who aren't aware, open SSH is effectively a remote shell command. It allows you to SSH or create a shell from one machine to another machine. The reason it's different than a normal shell is that it is secure because TLS is used, and therefore it's impossible for somebody to see the communication as it's going back and forth. Normally when you're using SSH, you have to have a private key stored in the file system of your device. So the key is actually you can do an LS. You can see the key. It says something.key if you've ever seen that. One great thing about using hardware cryptography is that effectively you can have the system not get the key from the file system, which is obviously susceptible to things like backups and people copying it and so forth. But you can actually get the key off of the USB hardware device, in this case the UB key. And therefore it's not possible for somebody to steal it without being detected. And of course it will not show up on a backup and so forth. So what I'm doing up here is I'm effectively trying to connect to my machine, and I'm getting permission denied. So what I can do with the UB key, and again all the configuration unfortunately is in the previous presentation that we never can get to, is that I'm using a utility called PKCS-15, which is actually a tool that you would run on Linux. This happens to be in a Ubuntu machine. And it's basically saying I want to run that tool to access my cryptographic hardware. I want to read key number one. And I want to output the public key that's stored in the UB key, the little device. So I can't take the private key off of here, but I can take the public key off of here. If those are familiar with public key cryptography, the public key literally is public. It's nothing secret about it. It's the private key that's the one you don't want other people to see. In fact, you can't see the private key. Once I put a private key into a UB key, I can't even see the private key. So I'm saying give me the public key from the UB key, and it actually looks like this, although there's a lot of dots here. So it actually would go really long, but I want to get on one slide. So that's what it looks like. So effectively what I do is I take that public key and I copy it into the SSH authorized keys file. And then I remove the public key because I don't need it anymore. And then when I want to use SSH to connect, I effectively have to tell it how to connect where to get the key from, the private key. And I now connect to that as that user. And I actually get a prompt, not for the password, not for the private key password. No type of going to type that out. But effectively any time I go to access the UB key, a second security measure is that I have to type a password of some type, typically five digits or four digits or six digits, to be able to access this device, access the little UB key. And in fact, once I do that and I type in the thing, I actually get an ID of prompt. And if I ask who I am, I've now SSHed in as Postgres when I wasn't using Postgres up here because I was somebody else. So my point is from this slide that you're basically going in and you're configuring, putting the public key out and registering it with that user, then you're using it to log in. PKCS11 is actually the protocol that we're using here. Here's a little more sophisticated example where I'm actually configuring SSH. I actually have a little script here that I've got a host name and a provider and I'm actually setting that up in the SSH config file. And now if I do that, I don't need to prompt for this OpenSC anymore. I've now registered OpenSC in SSH config and therefore I can just type SSH, the name of the person I want to become or the host I want to go to. I get prompted for the pin and boom, I am actually there. And of course, there is a URL there if you're interested. Another, actually, hold on, let me just fix that because that's annoying me now. Let me try to get rid of that little thing there at the top there. Oh, it went away. Okay, figure that one out. Okay, great. So that's another one. There is something called SSH agent. I'm not sure how many of you are familiar with that, but it allows you to avoid continually typing the pin in for the UB key. So it basically loads the key into memory, not on disk, loads the key into memory and then you don't have to keep typing the key. This is how you configure it. Again, I expect if you want to use that, you would probably download these slides and try it. And again, I run SS agent and I type the pin once and then now I can SSH and I'm not even getting prompted anymore for the pin. Or I could use this protocol here. Either one, I would work. And again, we have some URLs to kind of help you along. This is actually a script. I don't expect you to read it, but it's actually a script that I wrote that allows me to run the SSH demon in the background effectively at boot. I can run this and if SSH it hasn't been configured, it configures it and then it keeps it running so therefore I don't have to kind of keep typing it in all the time. So this is just a script if you're interested, feel free to cut and paste it and edit it. But effectively what it's doing is it's adding the key and then it's adding the agent PID and it's making sure that your SSH agent is running. And again, this is sort of another URL for you. And again, this is how you install it, SSH agent D. In this case, I made root own it and I just put it into user bin. Okay, old bin. Okay, again, if you're using SSH agent D, you would run it like this and now when you kind of log in it actually tells you some information about it and it works really well. Here's some examples. Again, SSH into somebody and you're becoming that. Okay, I would love to take questions but I have a feeling I don't have time. So if we have time at the end, I'll definitely be doing that. Number two, openPGP, you're probably familiar with that. It's sort of the command line tool that most people use for cryptographically signing things like emails and documents. This can also use the UBK in some really interesting ways. Again, originally designed for email but also now used for signing and encryption. It does file encryption, get signing, even Postgres stuff, actually uses this. Sorry. Again, a little history of openPGP and where it came from, GPG, if you're familiar with that name. Exploration of certificates and things. There's a lot of details here but I'm gonna have to kind of zoom through it but effectively this is how you install it. You're installing GNU PG, which is GPG long name and you also have to install something called SC Demon which is basically the smart card demon for Linux which allows openPGP or GNU PG-2 to access cryptographic hardware. That's what the SC stands for, secure smart card, I'm sorry, smart card demon. Once you do that, you can actually run GPG-2 and ask for the card status and effectively there it is, it's actually showing us the literal UBK information that it's pulling out of the little card that I keep seeming to reach for in my thing but it's so small that you probably can't see it still. But in fact it tells me it's a UBK, it tells me the version, it tells me some login data about the person, different key attributes and it even talks to me about the signature key, the encryption key or the authentication key. There's actually, UBK has several slots inside of it, it's not just one key, you can put a whole bunch of keys in there and in fact it's saying right now that those are empty. So this is telling me that my card, my UBK right now doesn't really have anything installed. Again, feel free to look at that URL if you wish. There is a GPG agent D that I wrote again to make use of this thing really easy, feel free to copy it. But here's an example of how you would use it, you'd start GPG agent and then you would actually, you can actually type GPG connect agent and you can actually reset the card. I know this is kind of gobbledygook but this is how you do it on a UBK to reset the card. Then you have to configure the pin for the UBK. Effectively here I'm generating a random number, that's six digits. I'm just shooting six digits out here, cutting the first six, making that my pin and then effectively I go in and I set my pin into that file and now I can basically run and I can change my pin and I set my pin to be that number. This is another password you have to use for the administration password, that's one's eight digits. So effectively once you've reset the card, this is what the card looks like right here, blank. Again, I told you there's a whole bunch of slots you can create in the UBK but right now they're all blank and of course GNU PG also doesn't have anything in it. So the first thing we have to do is we create a master primary key in GNU PG and then we create a signing key and encryption key and our authentication key all in here and then we have to populate the keys in here to match these. So effectively what we do is we generate all the keys on the operating system and then we effectively slice off the private key, the secret key, the private key and we copy them over into the UB key. Okay, remember I said that one of the beauties of the cryptographic hardware is that effectively your private key is not stored in the file system, okay? So the way you do cryptographic hardware with GPG is you effectively generate the keys on the file system and then you copy those files, the private part, into the UB key where no one can see them and then you erase that part, okay? And here's an example, GNU PG2 I say generate a key and this is a lot of, there's gonna be a lot of screens here but just bear with me. I basically am gonna say okay what kind of key do you want and then how long do you want it to be and then when do you want it to expire and then what's your name and what's your email address and you wanna go and you say okay and then you basically go and you edit the key and you can actually see this, I now have a public key in my in open PGP, okay? Again, a URL here for help. Then I can add another key, go in and add a passphrase. I want an RSA key in this case. I want now an encryption key to be added that's signed and we're gonna quit there, okay? No expiration in this case. So effectively this is a cheat sheet of how to understand the GPG2 labels. A is authenticate, C is certificate of creation. E is encrypt and S is signed. Remember I said there's four different keys that GPG typically uses. These are the labels you'll see. So now I'm looking at my key. I have one public key and in this case two public subkeys right here and if I toggle to look at the private part I have one secret key and I have two secret subkeys, okay? I do apologize, it is a lot of material to go in. I mean we're on slide 33 of 94, okay? So I'm doing my best here folks but you gotta take the cards you dealt. So again, if we look at the, at GPG itself we have three keys, we add to the card key and now this is gonna copy all of my private keys over into the system. So I'm not gonna copy the encryption key over. In this case now I have three. Now I've copied it over. But you notice that this one actually says it's in the card. See how all of these are public and they just look like one line, right? Two of these are public or private and they're still in on disk. And this one actually's already been transferred to the card, okay? I'm gonna do the same thing again. See again we have one transferred to the card. I'm gonna basically say copy all the private ones over and now if I look at my private key all of these are now in the card itself then I'm gonna delete the secret keys because remember I transferred them to the UB key so I'm gonna get rid of them now. I'm gonna just get rid of the private keys on disk so that they're only on the UB key and then pull them in. I know again more information there. So if I now look at my setup here I've got the three public keys. We're gonna now remove the encrypted subkeys to the card kind of run through key to card and now I'm gonna shove that over. See signature key has nothing, encryption key has nothing, authentication key. Now the card's telling me it has one, okay? Again, encrypt the key. Now I've got two of them over here card number right here, okay? And now I'm gonna do this one and I'm gonna do key to card again and now I've got three of them, bing, bing, bing. All three of them now are on the UB key, okay? And I'm gonna save, right? So now when I look at my UB key, we're back to the UB key, okay? We're not looking on disk, we're looking at the UB key. Now I have a signature, remember this was empty before? Do you remember the previous screen? These were all said none. Now in the UB key I've got a signature key, encryption key, authentication key and the dates, okay? So if I now look at my UB key, you can see they're all kind of marked. They all have card numbers on it. This is an important indicator. It says that there's a pointer here that inside GPG we don't have the key. We have a pointer to the card slot and that's what that's telling me, okay? And that's pretty typical. So now that we've sort of set everything up, let's actually use that key to actually do something. So what I'm gonna do is I'm gonna take the word test and I'm going to encrypt it with GBG2 with some armor. I'm gonna send it to, I'm gonna use that as my key ID and then I'm gonna decrypt it. So I'm gonna take the key, I'm gonna take a word, I'm gonna encrypt it with that key and then right away I'm gonna decrypt it. So the test goes in and bingo, test comes out, right? And the interesting part is that we've actually used the UB key to decrypt this. The public key was always on disk because we don't care about the public key, anyone can see it. So we don't have to transfer the public key over but the private key certainly used the UB key. Here's another example. If I do test and I do a check, I sign it with GPG2, I can actually say signatures made and it's talking about when I signed it. So that's a signing of that message, just a little different usage here, okay? You can actually use the open GPG and open SSH together. So remember I showed you before how to configure open SSH with a UB key. Well, you don't have to use the UB key directly, you can use open SSH. Open SSH can use GPG, which uses the UB key. So you're now putting a new layer in the setup here. So here's an example, let's pretend I can't log in. Now I can actually use, I can take my SSH out, I can throw it into a file and now I can cat it over to seven minutes. Okay, I can cat it into authorized keys and now I've become that person. This is a kind of software stack for cryptographic hardware. Here's the UB key over here in green, okay? We have four slots, one, two, three, four certificates here, public key, private keys over here and then there's an open GPG section inside the UB key and also auth slots and again, all the software that's used to access that is there, okay? So just a little comparison, if you've ever heard of PIV, PIV is the government standard for encryption. This is just a slide that talks about some of the advantages of when you would use open SSH, when you'd use GPG, when you'd use PIV. Again, I'm not gonna go into this because we don't have time. Let's finish off by talking about Postgres, which I actually know quite a bit about. We basically normally have a challenge in Postgres of how to store private information, how to store information without anyone seeing it. One of the tricks to do that is to place a private key on the client side and just as I use GPG to encrypt and decrypt, I can do all my encryption and decryption here. I can also do some decryption and encryption over on the Postgres side. Another idea is to just do, to encrypt it on this side and then just decrypt it on that side, have some kind of symmetric key. That's pretty simple. Here's an example where we actually create a table for each user and each user gets a symmetric encryption key, okay? And effectively what we do here is we, at the client side, we use open SSH and we create a symmetric key. Then we echo the symmetric key and store it into a variable. So here's my symmetric key, here's my encrypted symmetric key and then we create a signed hash of that. Again, a whole lot of open SSH going on in here sort of to encrypt that. What's interesting is that when you send a query to Postgres, we can have the client send its encryption key over to Postgres. Postgres can encrypt it and then store the encrypted data on the Postgres side. The problem here, of course, is you're sending this encryption over the network and Postgres is seeing that symmetric key, which is kind of yucky. You can actually retrieve your own symmetric key by doing a select and then you can decrypt the data on the client side doing the same thing. Similar here, you can get the symmetric key. This is actually what the symmetric key looks like in my particular example. However, that's kind of interesting, but notice if I take the UB key out of the server, or out of, yes, if I take the UB key out of the server, all of a sudden I can't actually do my encryption anymore because effectively it can't get to the key, the private key anymore, to figure out how to decrypt that. So it's kind of a multi-layered approach. You basically create a symmetric key and then you encrypt it with the UB key. That's usually the way most encryption happens. You don't actually use public key encryption or private key, public key encryption for data encryption. You normally use public key encryption to encrypt a symmetric key. That's the way TLS works. That's pretty much the way everything, most of them work. So effectively what this solution is doing is doing that. Here's another example, a little more complicated where you're creating a secret message and you're encrypting it with the UB key in this case and then you're basically sending it into Postgres and it looks like that. Now you can retrieve it and encrypt it. Again, it's pretty complicated. I'm not sure how many people are actually interested in this level of detail for Postgres, so I'm trying to go fast. But again, Postgres has cryptographic support in the server. It also has the ability to store cryptographic keys in Postgres as well. This is a little more sophisticated case where we actually use the server and we store the secret key in the file system, but we encrypt the secret key in the file system with the UB key. So we're storing the key on the file system, but the key isn't stored decrypted. The secret key gets another level encryption using the UB key. So every time Postgres starts, it decrypts that particular key and then uses it to encrypt and decrypt data. Again, very sophisticated. This is some examples of that. Here's an example of the actual key being used. Here's an example of exactly how you would kind of access it. You can get even more sophisticated. You can have per user keys. Again, this is really, this is very complicated. This is actually a server-side function that's written in the Perl language, which allows you to kind of do that. So I'm just kind of kind of zoomed through here. The point is that you have actually transparent encryption in Postgres by using this. And again, this is way more than you want to hear, but keep in mind that there are performance issues here too. Again, I'm going to try and take one question or two, but feel free to look at this. This talks about database encryption. Probably not something people are interested in so much. Let's see, so, okay. So let's take one question, two questions. I think I have two minutes to take some questions for people. Is it possible to make a backup of the private key when it comes to the UB key? So the question is, is it possible to make a backup of the private key? What we normally, before we put on the UB key, what we normally tell people to do, and you're absolutely right, is you would, when you create the key before, you're almost always creating, you can create the private key on the UB key, okay? But if you create the private key on the UB key, you can't make a backup of it, because you'll never see it. So what we normally tell people to do is create the key in open SSL, SSH, so create the key in the file system on Linux, make a copy of that key to a USB stick that you can take away, then copy it to the UB key and delete it. So you probably want to generate the keys on your Linux machine, make a copy of it that you can take offline, copy that also to the UB key, and then delete it from your file system. That's normally the way to do it. The normal way, actually, I would tell people to do it, is to literally put a USB stick in, create the UB key on the USB stick, not in your file system, right? Not in your Linux file system, but create the key on the USB file system, right? Copy that to the UB key, and then pull the USB stick out. So the key never hits your platters. Another question. Yes, sir? Why do you focus on UB key and, for example, I'm on TDM? I'm sorry? Why do you focus on the UB key in particular? Why do you then use like TDM that isn't bad at all? No, sir, a lot of the time. So why did I use UB key instead of TDM? I found a lot of open source support for the UB key, and the ability to extract it from the device, because if you take the key out, that machine has no, you know, so I honestly, it never came up in my research. I never actually saw it as an option for Linux when I was doing research. It's possible I'll take a look. One more question, maybe? We're good. Okay. Thank you very much. Thank you.