 consumer data. Do you guys agree? If you do raise your hand, I'm going to present it to you. So the question is why? EU. What did you say? EU with GDPR. Great. What else? Snowden, okay? HIPAA. Data breaches. Data breaches. Awesome. Exactly. So you guys know all of them. So we're seeing breaches, regulation, and decentralization that are really changing the security landscape. And that's what I'm going to be talking to you guys about today. So my name is Madison Current. I am a software engineer and developer evangelist at Ironcore Labs. And over the past couple of years, we've seen some really interesting trends in the security landscape, specifically around privacy. If you guys have read some of my blog posts, there's a lot of current events in the space, and there's a lot of regulation as well. So let's kind of brief on what the current state of privacy is. Back to our criteria here, right? I think that breaches, because of disclosure laws, are getting more and more hefty fines, and we're securing a lot more of them, right? Because companies now have to tell us. And we're also, it seems like every day in the news, we hear about another breach. Companies are getting closed off the right. And again, the question is what? Well, data proliferates. And essentially what used to be one system, an on-prem database that used to store all of our data, is now getting more and more complex. And it's getting more and more complex because of mobile, because of cloud infrastructures, essentially two or more in one app. And it's also getting more complex because of microservices and because of that derivative databases. So data that was once stored in one place is now stored in many, leaving a lot more of a vector for breaches. So let's say in a little bit. We've spent millions on security, but they still lost how to breach that affected half of American adults. This is because of the high complexity of the system. So they had a lot of disparate systems, and they had scams on a lot of the systems, but the scams were broken. And what turned out is that they have had 30 points where they could have stopped the breach, but didn't. The worst part of this whole thing is, is that it was entirely incremental. And this is my favorite one to pipe on, and I can't do a privacy talk without talking about it. Facebook. Seems like every day, if not once a week, if not every day, we're hearing another Facebook breach, and this is a different kind of breach. This is a breach of trust, where they're using customer data to, they're either packaging and reselling, or giving it away, or they're using it for purposes that were unsupposed to their users. So let's dig into a couple here. So when I said packaging and giving away data, so Facebook doesn't sell your data, they treat it for more users. So here's an example for you. So Facebook gave away data to Microsoft Bay. They gave away your user's friend list. They gave away data to Netflix and Spotify. They gave away data to Amazon. And they gave away data to Yahoo. And in return, they get marketing for more users. And they have similar deals with Apple. The reason for this is that they consider their partners an extension of themselves, only as it pertains to privacy policy. Facebook location tracking tracking. Who thinks that they can turn off location tracking on Facebook? Okay, no one. Cool. I should have waited to turn this slide. So when you turn off location tracking on Facebook, they stop using your GPS, but what they still continue using is your IP address location. So they still know where you are pretty, pretty close to accurately. And again, what they're doing is that they're lying to the public, they're misleading us, and they're breaching trust. So what we're seeing is that companies are being irresponsible with data, and they're undermining customer trust. And as a response, we're seeing global, public, and regulatory backlash. And we are the collateral deal. Let's go on a little bit of the brighter side now that we took it to the spectrum. All right, so privacy laws, global privacy laws. In the last year, there has been either enacted or passed six major privacy laws around the world, including GDPR in the European Union, CCPA, California Consumer Privacy Act in California. There's also been privacy laws in Japan and Brazil that have come down to that. There's hundreds more following. Also there's kind of states are pushing for their own privacy laws based off of CCPA and GDPR. Some of those states are in Mexico, Massachusetts, and Washington are pushing for their own privacy laws. Last is decentralization. So who here has heard of blockchain? That blockchain is really born out of the same ethos. It's trying to solve some of the same problems. Now I'm not advocating for the security of the blockchain. It's not cryptographically secure. It's hashing, so we can talk more about that. But it is born out of the same ethos, meaning that we're decentralizing authority. And it's a way that we can reconstruct the behavior of the internet, which is becoming more and more centralized over time. And it's also a lot of people that are developing blockchain believe in the same concepts that the internet was built on, which is the freedom of information. Okay, so that's all good and great. But what are the implications on you as a software engineer building your apps? We kind of talked about the whole global state compliance regulations coming down the pipe. But this has a direct effect on the software that you're building because it affects the data that you have in your applications and what you need to do and how you need to architect your applications to handle that data. So now we need to architect for privacy. And that's what I'm going to talk to you about kind of in the continuation of this talk. So three steps that we're going to follow is that we need to analyze what data is in our app and see if these even pertain to you, these regulations, right? And the data that you're holding. Then we're going to architect solutions. So we're going to look at systems and see what kind of tools are available to us to comply with regulations that are being put on the data that we're holding. And then last, I'm going to show you kind of a quick demo of end-to-end encryption, which is one of the ways that you can handle analyze first and then like to interact. Okay. Who here has sensitive health information in their applications or the applications that they're building? Okay, keep your hands raised. Okay, who has finance information? Okay, any sort of user-generated contents, anything like posts, recordings, chat logs, support requests, anything like that. Keep your hands raised high. What about user names? This affects all of us because this is the data that is protected under these regulations. So data covered, again, user name, email, IP addresses, location, address, health information, any sort of sexual orientation. And the biggest one, again, is to reiterate, any user-generated contents is protected. Okay, so how do we architect for this? This seems like a big, hairy problem that I don't want to handle. Okay, there's a couple ways we can do this. And by the way, in this talk, this is not legal advice, but we are going to go through legislation to kind of figure out what our obligations are and how we handle this data. Okay, so looking at Article 25 of GDPR, it says that data needs to be protected by design and by default. Okay, it's a couple things here. It means that it's incumbent on you as the application developer to protect the user's data in your application. And you need to design your applications accordingly. I think I got this later in the presentation, but I think it does make here, as you're designing applications, it's really important to document how you're going about designing, to show that you were designed with privacy in mind. Okay, one of the core concepts here is minimization. Minimization means that you're collecting only what you need, only the data that you need, and you're only holding it for as long as you need it. So that means if you are collecting birth dates, but you're not using that for any reason, that's illegal. Under GDPR, this is where that slides. Yeah, but document, document, document, everything as you're going through the design process of how you're building your application so you can prove that you built your applications with privacy in mind. So then we're going to go to GDPR, Article 32, the security of processing. And I can, for the life of me, not say this word. This is what I was practicing only yesterday. Pseudonymization. Everybody try it. Pseudonymization. Pseudonymization. We're going to call it de-identification from now on in the presentation. So just going back here, this is really the de-identification of personal data and that you need to product against abuse and abuse of insiders, meaning that if somebody had access to the database, they couldn't tell who each log entry belonged to. Right? So de-identification. So this means that we put the data in our system in a way that we can't recognize who a person is. So they could have information about me, but they wouldn't have my name, Madison, in the table. So the kind of unique idea you know I did in my work, right? So this is a way that you can comply with your degree. It's a potential tool. There are some issues in it though. We're going to look at an article that New York Times wrote about its de-identification and their process in being able to re-identify the users from this data. So it turns out that weather apps like Weather Channel, which is owned by a subsidiary of IBM, tracks your location data, de-identifies it, packages it up, and then resells it. Now when that's combined with public data sets, it's very easy to re-identify who someone might be. And that's exactly what New York Times did. So they track location data of individual or bought this data set and then combined it and they were able to pinpoint a woman and they came up to her and they said, so how was that doctor's appointment last? Because they knew everywhere she was going. They knew her workplace and her home. That's easy enough to identify you, right? So and then they looked at the patterns and they said, well, where is she going that's not those places? Oh, she went to a clinic. Oh, she stopped at the store. Maybe she went and stopped at A&E at a certain time. It's pretty private information, right? And it's easy to put two pieces together to re-identify an individual user. And I would argue that it's really not okay. It's not enough. Okay, so let's talk about encryption. So full disclosure, I work for a company and we provide an encryption solution. I'm not going to talk about that today. What I am going to talk about though is the technique of encryption and how it can be used in your applications. And what some of the benefits are. Okay, so oftentimes when I talk about encryption, I hear like, I've got encryption. And most of the time it's transparent disc encryption. And before we dig any further, I just want to kind of dig into that a little bit. So transparent disc encryption is not enough. It encrypts data while your machine is off. But as soon as it's on, what's transparent to you is also transparent to potential hacker. So transparent disc encryption is not the answer. We're going a little bit more in depth. And then another thing to note here is that when we keep flipping back between GDPR legislation and technology, GDPR is not prescriptive on the technologies that you use or how you implement the features that they're asking for. But they are asking for specific capabilities like logging of every access element, like knowing who's accessing it. Right? And there are certain ways, technological solutions to how to implement that. And the truth is that they're not going to look at the technical implementations and say, oh well they want their research done everything they could. They're going to say, no, if your data is lost you probably didn't do enough. So let's take into some architectures. I'm going to show you three architectures and we'll kind of talk through them. If you have questions in this piece, please ask them as we go through. So three patterns of how you can use encryption and architect that into your application. Again, these are based on public cryptography. There's open source libraries for these and you can create your own encryption services. So first we're going to talk about server side proxy and what that architecture looks like and some of the benefits of it. Then we'll look at server side application. Mr. Hyphen. Kind of the server side application and what that would look like. Again, some of the benefits and trade-offs. And then lastly we'll talk about client side encryption and this is what all of that wants to do with you guys as kind of the implementation piece. So server side proxy. Here we have our device at the top. It talks directly to our application and then that application talks to the encryption proxy which has access to individual keys that it then is able to unwrap and send back to the application. So the application here will say, I have data that I want to decrypt. Can I have the key to decrypt it? Right? And then it asks, that event is logged. First, so Apple is an access control list meaning who is allowed to see this data and who is not, right? It's checked to see if the application can read and then the event is logged. Now one thing to note here is there's not very strong authorization between the application and the proxy letter in this architecture and that can lead to some potential downsides. I'll play this real life so you can't see the server side like the server block just kind of a bummer but it cuts off right after the device. Any questions here? Our potential architecture is the server side application and as we've been doing more and more market research internally we're finding a lot more traction with this kind of architecture because it relies on servers that are reliantly fat. And so in this architecture the application will request keys from the encryption service, decrypt and then be able to pass that back directly to the device. I was just wondering, the encryption keys would that be something like a JWT? So no, they're a little bit different. So JWTs verify identity whereas encryption keys are they're more private, they're longer or lasting than JWTs and they are the key to actually go ahead and decrypt the data. So if you don't have the key you cannot like re-audit, you can't come up with it again. It's not backwards, right? With JWTs you can ring pass it but most of the time in these systems JWTs are used to authenticate a user and then that's kind of proving the apple or proving who somebody is and then they can go ahead and get the key to decrypt. So that's normally how these systems work with identity. Other questions? Yeah, so in the other one the encryption proxy just has encrypt and decrypt functions whereas in this it's actually passing the key back to the application only sort of memory for a short period of time. So it's the difference in key now. Am I saying? The proxy to the name. Exactly. Application. So this is probably the most robust of the three architectures but it's a lot less common. So the device actually has the key on it and the device is the only thing that can decrypt. Not the only thing. Sorry, the point of use is the only thing that can decrypt. So disregarding this for a second what you have is an application that sends data to the device. The device has the key on it decrypts the data and is able to view decrypted data. So the client is the only user who can decrypt that data. Audit events happens from every single interaction there. But what you might be asking which is kind of the logical next step here is what if I have a service, a microservice in my architecture how do I access that data? Well what you can do it is that you can give that microservice a set of keys just like the client. So when I say point of use it can be a service as well. Give them a set of keys. Give it a set of keys. It can decrypt and every time that service decrypts it's locked as well. Which is what you need under regulation. Questions here? If you can do a key wrapping technique here where you can pass them an encrypted key that the application never sees the decrypted version of the key pass the encrypted key to the application and then the client can decrypt it. But to your question I think it really depends on the application. So while this is maybe I don't want to say this is idealistic but this may be a better fit for a green field app. They're really from the ground up but in the case of a brown field app or something that's already been built before that you have services that you can be able to talk to each other retrofitting something like this is much harder. So what you'll notice around all these architectures and that's such a great question is because it really depends on your tradeoffs. And what you'll notice is that there's some sort of separate service encryption service that allows you to log the point of access at every single increment, right? So what this is for us is it's an unavoidable access control and audit logging layer that ensures that nobody can see the plain text of our database without going through that layer, right? And that's what's critical for the legislation is that piece because we need to know who's accessing it and when they're accessing it and how often and be able to turn it off, right? And so by this having the access control list we can remove somebody from the list and they can't access the data anymore, right? Which is exactly what GDPR pushes forward. And same with CCPA. So next piece is a quick demo demo guide to be on my side. So I was going to show you kind of an implementation of the last architecture just the encrypt functionality and show you that text can be encrypted on the client before it's ever sent to the server. So the server never sees the encrypted text. Oh, not going well so far. This one? This one? Okay, so what I've got running here Okay. So what I've got running here is I've got a React app that is using how we recognize that material design it's using Redux regrettably not using TypeScript and it's connecting to a data store database in the back end. That doesn't really matter. What I want to show you is the actual request here so really good password I want to make sure we do that So to your point here's the DWT, it's off things for DWT So what I want to show you is that in my Redux action I'm actually calling the encrypt function on the client before anything is ever sent over the network. So while my message was an important information it's now encrypted and when this is stored on the database it can't be viewed in plain text Does that make sense? I can go ahead and decrypt that because I have the key to decrypt it but it was also encrypted on it I think we're still doing okay on time so I'm going to dig into a couple more articles in GDPR Another one is the right to erasure meaning that a data subject or an individual user has the right to ask you to delete their data and any data that you pull up So think about this in terms of your database architectures If you have a store and only one that's easy enough to do, right? But what if you have a message bus that's feeding all of your micro-services downstream all of those micro-services have separate databases becomes a lot harder task to achieve in really complex systems and this is kind of the origin of a lot of the problems that we're running in that we're taking when regulatory backlash aren't so unless you have legal obligations such as tax purposes health reasons you are not allowed to deny these requests right? There is a little bit of a loophole that it's like well it's way too hard to not see what you might think you can get through it in GDPR that's not the same for CCPA or legislation coming down the pipe that's getting stricter and stricter around what your legal time But what is a really cool technique here is what I call I don't think my co-workers like this term but I really like it it's called crypto shredding so the idea that if something is encrypted in your database, if you delete the key or you take somebody off the access list it's still on the database but nobody can ever decrypt it because the key's gone so it's a really cool way to handle this there's also a lot of backup solutions that are implementing this for you so they actually support the rights that you've forgotten and they're helping you with access blocks so at the same time that we're seeing regulation coming down the pipe we're also seeing other tools coming and being at a good disposal but it's not really a one tool this is going to solve GDPR for me it's a set of tools and design practices that are going to need to be put in place to really really solve this okay so article 7 conditions for consent this is an interesting one so it's your legal basis for holding data and you need to have a legal basis for why you hold data in your application so you can't just overly collect and be like well we don't use it it's fine, you can't do that anymore there's some really interesting tools around managing granular consent so these are some other tools that I found that are trying to solve this right now definitely not endorsing them, try them out there are things out there for you what they do is that they give granular consent or they allow the user to give granular consent to different APIs or services that are accessing their data then you can turn on and off and see how it's being accessed and they also help you manage some of the complexity because this may seem like it's kind of like cookies well to show accept cookies but it's not that easy anymore and the reason being is that you need to show how to track how you're getting data from individual users how long you have it for and when you change how you're using data or any third parties that might be using that data you need to get fresh consent right because you can have sale agreements that users haven't agreed to and specifically if you got data from a third party this can help you track third party agreements, contractual agreements for how you're using data help manage that because it is a basic problem so in conclusion we think that we know how to architect applications for today but technology is only part of the equation for us now and we cannot treat consumer data as a property of the business regulation and backlash is putting the right of the data back on the hands of the consumer and that changes how we architect applications and the truth is as an implication on our software developers is that we need to be aware that we face and that come along with steep financial burdens if we mess this up and reputational penalties from now until from now on we need to be able to build our applications with privacy in mind thanks for having me here first question for you great if I talk to my echo friends, my old teaching friends and so forth about things like privacy they say I don't really have anything to hide why do I care should they care? they definitely should care so I actually was watching what I did my free time because I watched a bunch of TED Talks so I was watching this TED Talk and I was talking about exactly that statement there as to I've heard that a lot as well well I have nothing to hide, what does it matter? but what I kind of shown this example is that data proliferates and is no longer in the control of the consumer and so I think that that statement is from a government standpoint saying that the government is going to watch I'm using data but what about companies that are reselling that data and using it to kind of manipulate what I'm seeing no more about me and see things that are private and they change if I knew it was public it may change my behavior for me personally one that always caught my attention was when insurance, car insurance companies started offering you a discount if you install the old tracker and I'm like like this is not going to be good for me if they're tracking all kinds of data so even if you're not if you don't consider yourself a really privacy focused person there are plenty of examples of how this data can start to affect you in small ways that's a good time quick question about GDPR and decentralization so GDPR requires the right to be forgotten but if someone is decentralizing data on blockchain and blockchain can't be deleted how do those two coincide? yeah I know it's a really interesting problem and it's one of the limitations I think of blockchain there are potential solutions with encryption what scares me with that is whenever you have immutable logs as technology gets better and better over time what might be secured today as far as our encryption algorithms may not be secure in the future so I think that's a big problem it's a big limitation of blockchain some architectures that I've seen are potentially pointers to documents so you're not actually storing any information on blockchain I mean blockchain is just the technology that we're using but it's really a thermal log it could be any system that's using a thermal log there are major limitations and some worries with that but if you're storing the pointers to the data you can still go ahead and delete the data potentially there's some architectural approaches to that so like client-side encryption does that end up becoming expensive to actually do that encryption on the client-side does that end up affecting the UI or the user experience at all in having to do that on the front end and then sending it to the server yeah I mean there are performance implications specifically with now this is probably getting too in the weeds with multi-option encryption when you're encrypting to an entity or a group and then a user encryption operations can get really expensive that's why I think just from what I've seen building it in a house can be really complicated there are solutions out there there are credit libraries like iron cores making one actively right now and working on performance issues we're using technologies like WebAssembly and Rust and we've seen some major major gains to the point where it's no longer a big cost but that takes optimization and it takes tweaking your algorithms so that's not the right term but finding the places where you can make performance benefits going off your example I recently built an application where are you I'm sorry I recently built an application using the same technologies and we're basically getting a JWT from our back-end authenticating the user once they're logged in and using it for ongoing requests of the database what type of behaviors would an encryption function have or a de-encryption function have and how would I be able to test that so it depends on the library so it depends on the library they decide to use but it would so JWTs are often used for off-offing which you just described what encryption does would be another layer of protection so you could use JWT to unlock a key that can then decrypt the data right so JWTs aren't being used to encrypt data that's sent to the server right is that true yes it has that was basically like just storing it in like the read-up store which is not like the most secure thing to do so I'm just curious like how I like ensure that it actually is encrypted once I have that gene yeah well based on the example I have all my code that I showed in the example which I'm happy to show you I'm using the ironweb library but it's just it's using the key like an encryption library to encrypt data on the client it's different from the JWTs although it's using JWTs but I'm happy to send you source code I'm using Redux and React in that sample app cool yeah I'll send it to you alright thanks Madison