 So, I seem to be the fall guy here, I mean whenever there's a lightning talk, people say you know go up and talk something, right? So, I did talk about Excel, David, for yesterday. Today I'll talk about... Because we love you so much. Thank you. I love you back. So, basically about myself, my name is Nikhil Sontak. I'm a co-organizer along with Samir for this Fiji Asia. I've been in the community for the last 10 years. It's good to have my first boss, Farz, sitting here with you who hired me 10 years ago at Enterprise TV. And that's how I got introduced to Postgres. And been at it for the last 10 years now. So, this is the name of my company, Security TV. I'm the co-founder there. And basically, we are trying to provide encryption as a service. And I'll try to explain what we mean by that. But first, before that, some preamble, right? A lot of sensitive customer data is in clear text. You have... every website has a user registration screen, you know, user ID, password, sensitive information about where they decide what is their age, date of birth and so on and so forth. And most of the data is stored in clear text. And we've seen an empty number of breaches happening, right? I mean, especially in the US, they've had an OPM and, you know, Target, Sony Online. And basically, the most interesting one is actually medicine recently, right? The database was hacked. All the information was stored in clear text. And people were approached to pay ransom money, right? That is the kind of stuff that we're talking about. You have a database, which is good, but if you're storing your data, sensitive data in clear text, then you are going to get, you know, setting up yourself for some weird stuff that will come along your way, right? Sometime soon. So, basically, in 2015, there were 200-plus data breaches. And only in 10 or so cases was the actual data stored encrypted. So, people got access to their database dumps, or somebody hacked into their database, machines, relays, whatever. And they just gave you a PG dump or something or, you know, whatever, select star from sensitive table. And all the data and all its glory was there for you to pillage and go through all the salacious details. They were all there for consumption outside, right? So, only 4% of the data was encrypted. But you've got to ask, right? You know, why only 40%? Why not, you know, a figure more than that? It's because whatever current encryption solutions that are out there, they are expensive, difficult to implement, and they're very time-consuming. And basically, you know, typically people have a database and they cannot say, okay, let's have a database solution, let's have an encryption solution. You know, you need to marry them together. And, you know, then that integration takes a lot of cost. You need to hire a crypto expert to actually verify that whatever you're using, it's not breakable, right? I mean, there's no point having a crypto expert who just does, you know, some kind of a simple hash or something, right? I mean, somebody will actually go and, you know, break it up in a couple of days or something. So you don't want that kind of, you want ironclad security and peace of mind when you're thinking about encryption, right? And that's why when you actually talk about proper encryption, enterprise gate, then it becomes expensive, it becomes difficult to implement, and obviously it's time-consuming. You know, you need to take time out of your application programming lifecycle, you know, spend time to think about your cybersecurity solution, think about how best to integrate it, and so on and so forth. That takes some resources from your actual development. And at the end of the day, every web application developer, every application developer, every user, they just want to do their own thing, right? Security is important, but, you know, that is not their main concern. They just want to run their health IT firm or their big tech firm, right? That is what they want to do. So, and that is why they say, OK, let's get on with my stuff first. I will look at security later on, right? But then it leads to unpleasant things that come up, right? OK, so we will try to address it in some ways. So security is a cloud-based encrypted backend as a service product. Our main product is identity management, because that is where the maximum amounts of breaches happen. So basically, let's say you are starting a new website. I can buy a website, you know? So typically you will have all of these screens, right? There will be a registration screen. There will be a sign-in screen. Every user will have a profile where there will be sensitive information about that user. And you will be able to provide stuff like reset password, forgot password, two-factor authentication, and so on and so forth, right? Basically, people can just use our REST APIs over STTPS, and then they get all of this functionality on the cost. And all of that sensitive data is stored inside our servers, our base Postgres automatically, without the user having to worry about anything. So yeah, I mean, what are we replacing, right? For developers, we are replacing three-plus months of development time, savings and costs, and uncertainty about the security of customer data. You know, saying, okay, my sensitive information is in place, is taken care of. Compliance is a huge, huge factor, if you're talking about health tech firms or financial firms, you know? Compliance, regulatory compliance, it buys for the health industry, PCI is for the payment card industry, right? So they have to ensure that whatever data they are storing, it is stored in a encrypted form, right? So with us, they get that as well. Yeah, so as I said, you know, you don't have to write any lines of crypto code. It just takes a few minutes to set it up, and then you can just have encryption as a service in place. We also have some dashboard, which can give you some analytics. It takes, for example, if somebody's trying to hack in, and you will see, all of a sudden you will see 100 failed attempts in the last 10 seconds, 10 minutes or so, right? And somebody's really trying to do something, right? So let's say a user logs in, usually logs in from Singapore. And then at the next moment, he appears logging from India. You know, what's going on there, right? How can the same user log from India within a span of two hours? You know, somebody's trying to do something funky there, you know? So this kind of user behavior analytics can be done with our platform as well, right? And we're also working on data exfiltration. So all of this basically is a part of that. Yeah, and you know, there are like so many developers out there, approximately a million will need strong encryption. And we're trying to, you know, for various reasons, the compliance needs are only going to grow. So, yeah. Okay, let's get to the postgres angle, right? So we modified postgres skill to implement TDE. TDE stands for Transparent Data Encryption. So security beat is a pkscs level compliance. So key management is a very important piece in any encryption offering. What value store your master key, right? And if you're using PCCrypto, for example, you know, where does that key reside? You know, it cannot be on a flat file, right? In fact, that is the standard mistake everybody does. Just store that data in a flat file and assume that nobody will look at it. That doesn't work like that. So key management is a very, very key piece of this. And set it in these pkscs level compliance. We have integration with AWS KMS. AWS is a key management service. And basically, when our postgres instance starts, it connects to AWS to get the decrypted key. And what we did was we modified the page layout, the postgres page layout, the age page layout, and we added 32 bytes at the end of each page. Just, I mean, there is a special area, right, on the page. After that, we added 32 bytes. And that is where we store the initialization IV and the authentication code for that page, right? So in some ways, this is similar to the text that we have nowadays on the page layout, right? So basically, when you're writing a new version of that page, a new IV is generated. And using that IV and the master key, you generate an encrypted version of that page. And in our case, the encryption algorithm creates the same size buffer as the past in clear text data, right? So that is the view. I mean, others, it won't work, right? I mean, if you take 8192 minus 32 bytes, right, and you pass it to your encryption function, it needs to return back the same size buffer. Otherwise, you know, the page will overflow and you will not have proper data, right? So, yeah, our algorithms ensure that you get back the same amount of encrypted data, the same size, right? And this is why writing down, and when you're reading, obviously, you first, before it gets into the shared buffers, you have to first generate that data using, again, the IV that is stored. So basically, the storage manager rates that page, looks at the last 32 bytes, gets the IV, and uses that to make it information and then gives it back into the shared buffers, right? So that is what we have done so far. To be D, you know, as of now, we have done a TDE for table pages. And I think many solutions out there are just okay with that. I think MySQL also does that. Even SQL Server, I think just does relation pages and encryption TDE. So we are there, but obviously, we should also be encrypting the wall-offs. And in the future, right now, the encryption T is for the entire cluster. But in the future, we plan to provide encryption T is called database and also for table space, as we go ahead. The second important component is called as the security encryption gateway. And for that, we modified PG pool. So here, again, when PG pool starts up, it gets the key from AWS KMS, and then it also consults a local Margarita PostgreSQL database. And that database contains a key for each column that needs encryption support, right? So based on that, we have different types of encryption, probabilistic, deterministic, tokenization, hashing. And based on your requirements, a specific key will be stored there. And when it starts up, it basically concerns that and gets the keys for each column that needs encryption. And when a query comes in, it walks that query, it identifies which columns are being accessed, it ascertains whether that column needs encryption or not. And if it does, it does it on the fly and then basically it modifies the query, right? So just to give you an example, let's say you have a table and you said that this first name column needs to be encrypted, right? So this query comes in from the application, it reaches the security encryption gateway, our modified version of PG pool. And what it does is when it walks the query, it identifies that this column is an encrypted column, right? And then on the flag, it converts that into a form which will be understood later by the database, right? So the above query gets converted from select star from table, where our internal name for this column equal to this encrypted value, right? So basically it takes this Nicholas value, it applies the encryption key that is assigned for that column and rewrites that query into this new form. Because this is how the data is stored inside Postgres, right? And any questions here? Yeah. And what about the data that you will see, like the first name will also be part of your output set. Yeah. So will it be the same gibberish text or is it going to be the same value? So this is the inward query. When the result comes back, PG pool is the duplicate first before it's sent out to the map. And PG pool is talking to a key store and it is parsing a query. So in that query parser of PG pool, you have done modifications so that it can do the replacement. So star is expanded for every column and whichever column is encrypted, you replace that with the PGCrypto function. Not PGCrypto. Yeah. So you are using a ES256-based encryption piece and it looks like a state-of-the-art standard encryption that is out there, right? And obviously we've added support for inserts. Basically, if you're doing a migration from vanilla Postgres to our version of Postgres, you'll have a PG dump and basically then it will be run via the gateway and it will convert all of those columns involving the insert into encrypted form using the keys from the metastore and then store it inside Postgres, right? So yeah, there's support for inserts, update, delete queries. We also added support for joins, yeah. Encryption. Encryption nowadays has become pretty performant. I mean, there have been a study where the encryption is... the throughput is like 2GBs. Yeah, the encryption itself, but going through the gateway, figuring out the... So over a vanilla PG pool, we compared our stuff at its 2 to 5% and that's an acceptable overhead for somebody who wants encryption, right? I mean, they are okay with that kind of an overhead. So yeah, and we also have support for join queries and the road ahead is, you know, we can obviously, you know, keep on rewriting more complex queries, right? I mean, Postgres, we had a customer who gave us like a 300, you know, characters query, right? It was like really weird. You know, there was like sub-selects and, you know, further sub-selects and weird joins and aliases everywhere, right? So obviously our rewriting logic needs to understand a lot more. But having said that, there's very basic support for inserts, updates, deletes and joins and all of that. Is it going to affect the query plan? No. No. So it's basically the encrypted column is a Varkar type and you can have indexes on that inside Postgres, right? Yes, sir. Do you replace the columns with an encryption function only when it is equated to a literal or do you also convert it when it is equated to another column, like in shares of joins? No, so, I mean, if it's a table.call a equal to table2.call b, that will go as is and sizes, yeah. And even in case of literals, you convert, so you actually apply the encryption on the literal itself. So actually it will use indexes, right? Yeah. So we, encryption can support equality-based searches. Yeah. Because they're not applying the function of the column itself instead of the literal rather. They're moving on the other side. Yeah. But your comparison would work only if, you know, they're using the same keys, right? Yeah, yeah. If they're not, then it will not give you the same result, right? Yeah. And it also has to use deterministic kind of encryption. Otherwise, if it is probabilistic, then the values will be different in both the tables. So it depends on that. Yeah. Yeah. So this is basically the architecture. Your web app, your mobile app, will basically talk to what we call as the gateway, which is PG pool in our case. And it will be called PG or STTPS always. And basically we have these REST APIs, which will be, so the applications will be using REST APIs to talk to, which is our Java, and then that will be internally doing queries against the gateway. The gateway will automatically rewrite that query into its encrypted form and basically store it inside the TD-enabled database, right? Now the database could be vanilla Postgres. It could be AWS, RDS. It could be any version of Postgres, right? If you want to use us, you get two levels of encryption security. The gateway provides column-level encryption and if you choose our version of security in Postgres database, it will also give you TD, right? So some people have TD needs as well. Data at REST has to be store encrypted, right? Yeah. And yeah, I mean, we're seeing a lot of demand for this from enterprises, basically. I mean, I initially thought it would be a developer play, but enterprises are the one which say, you know, hey, I want to use this inside our own virtual private cloud. You know, so that's what... So basically, we provide an AMI which contains all of these components and you can just spin it up inside your virtual private cloud and just point it, point to it, and start using the endpoints, right? Okay, that's what I had. Any questions, Stephanie? There's a lot of migration issues, right? Like you have to do a lot of migrations to get people on board with your project. So how do you do that? You have to, like, tunnel everything through your gateway to get them to be or is there a way that you can do run, like, run coffee and have that encrypted? So typically, you know, they might not want to migrate their entire database, right? I mean, they would identify, okay, that these are these three, four tables that need encryption and they would give a PG dump of that and what they would do is basically run it via the gateway which will encrypt all the columns on the fly. And then what we have something called as a hot switch, basically, if there's a table X, we create an X underscore SEG, we load into that and then at the last moment, we basically just do a rename of that. We rename the old table to X underscore old and we rename the new to X underscore from X underscore SEG to X, right? So that can minimize the downtime and all of that. So yeah, that's possible. Okay, thank you.