BSIDESKyiv 2018 - ANASTASIIA VIXENTAEL ENCRYPTION WITHOUT MAGIC, RISK MANAGEMENT WITHOUT PAIN

Before we get to the boring intro, I have a question for you. Who read this book? One hand. Really? Two hands. You are my idols, I know one of you, and I will meet you. I just ask because I really like this book. It is one of the latest books, one of the most modern books about modern cryptography. If anything, it is not an advertisement. I just like to read it, it is very easy and interesting to write. If you are suddenly interested in cryptography, I highly recommend it. Actually, after this picture, I think you You might have guessed that today we will talk about cryptography. My name is Nastya, I am a product engineer

of Kazak Labs. If you listened to Dima's first report, you probably heard a little about the practical part of what we do. And today I will tell you about the more abstract part, about how encryption, how data protection methods help you in your infrastructures and why you should use it there. My task as a product engineer is not only to write code, although I do write code, I don't like code. It's not only to write code, it's to unite the world of original crypto scientists and various security engineers with the world of ordinary engineers, who are alien to some paranoia, to build a bridge between them. Cryptography. What do we think about when we talk

about crypto? In this report, for the next 40 minutes, "crypto" will mean "cryptography". We will talk about Bitcoin, Dogecoin, Ethereum and other things in the QoLuars. Cryptography. What do we think about cryptography? Of course, about a bunch of different algorithms: symmetrical and asymmetrical, hashes, elliptical curves, etc. By the way, about hashes. A question for you: among these wonderful hashes, who still uses MD5? Can't you hear the question or are you shy to raise your hand? Okay, let's wait for a few people. People, come in, we want to talk about hashes. Great. Let's try again. Who still uses MD5 as a user password hashing algorithm? Who uses SHA1? SHA512? SHA2? Okay, admit it. Well, 256 is also SHA2. The idea is that, of course, you know, this is an

advanced stream, MD5, SHA1, this is all old school and so on. It is not worth using it, collisions. In principle, SHA3 is also not worth using for hashing passwords into the database, obviously. And what is worth using to store passwords into the database? Tell me, how was it in the comic book? Three words, five letters and one number. Pb, Kd, F2. Well, in general. It was a warm-up about hash, a little about how to keep passwords, there is a link to Wasp. In fact, cryptography is not only about algorithms, and, of course, not only about hash algorithms. You have probably heard what everyone is talking about, this famous triad: integrity, confidentiality and authenticity. Confidentiality, authenticity and integrity. Sorry, I

know another terminology. And you probably also asked the question: "Ok, encryption algorithms are cool, but how to store keys?" How to confirm that the public key is valid and relevant? And cryptography is not only about hash, encryption, keys, and not a super magic wand that can turn all data into super safe. For us, cryptography is a method of controlling the surface of the attack on data that cryptography protects. It is about algorithms, keys, trust schemes between them, and about the places where your infrastructure is encrypted and decrypted, how long keys are stored in memory. All these questions allow you to determine the attack surface on data. And since we are already talking about the attack surface, what is the attack surface? Basically, it is any place in

your infrastructure, in your processes, in your code, where sensitive data appears. In cryptography, we are not only talking about sensitive plaintext. We also believe that sensitive is the key. We also believe that sensitive can be a kind of trust method. About attack surface, this is a rather narrow definition and only in the data security domain, of course. This is exactly what we are focused on. For those who have just entered, Today we are talking about cryptography. And we are talking about cryptography not in terms of what algorithms to use, but why it is necessary and what it gives us in our infrastructures. Okay? Yes, yes. I say, a responsive audience. Nice to talk. So, let's continue with the attack surface. Why should

we define the attack surface? Obviously. If we know it, we can monitor suspicious behavior. Moreover, it is much easier for us to monitor not the entire infrastructure as a whole, but a specific place in this infrastructure. And if we know what kind of place it is, we can predict what patterns of behavior are correct and what patterns of behavior are wrong for this place. Accordingly, we can raise our monitors when necessary. For those who came, listened to some cryptography and are going to be scared and leave, This slide is an important key take away, after which you can go to another stream, go to dry coffee. To put it briefly, the mechanism of narrowing the attack surface depends

on: proper control of keys, avoiding plaintext, direction of all efforts to make the keys and plaintext as small as possible in memory, and in places far away from encrypted data. And of course, it's about monitoring. Monitoring everything as a super-real porn. In this place, if you want, you can leave. I will remember your faces. But, so to speak, free choice is all. No? Continue? Yes, yes. Great. Let's move on. How to control the attack surface? on our protected data. We will consider several examples, several typical architectures. And for these typical architectures we will talk about sources of trust, how to use, what encryption methods, what algorithms to use and how, what it gives us, and most importantly, what we would like

to get from it. Not just to say: "Wow, I'm good, I can encrypt data, cool!" But to understand what, where, why and how. The first case is super simple. I'm sure you've all faced it. It's symmetrical encryption. You have data, you have a key, you have a encrypted container. As a result, if you store the key next to the encrypted data or pass the key to an unprotected channel, then

Difficulties in personal life. This puts your security at risk. Even implementing such a simple cryptosystem can be easily imposed. Where is the attack surface here? We have already talked about the attack surface. Where is it here? In this example, it is almost everywhere. Because as soon as the encryption key is leaked somewhere, the data can be decoded and, accordingly, It's a very simple mechanism, a very simple idea that many people use. But in the world of security, it's comparable to the fact that you take and write a password from your laptop on a piece of paper, paste it here and you will watch from time to time. Like, cool, well done, you use the password, but... As

we are talking about cryptosystems, let's see what cryptosystem is. This is the most simple example of cryptosystem. Cryptosystem is a combination of one or more encryption methods, but not only. mechanisms of key management, mechanisms of trust management. In principle, we can say that in any software that has at least a little cryptography, it is already one or several cryptosystems. If everything is done correctly, you are in your business, in your products, in your infrastructures, "Let's do something cool with cryptography in my products" If you just wake up in the morning and decide, you probably won't succeed. Because real cryptography is built into business processes. and is a part of them. Then you can determine what data is important to

you, how to protect them, what is important to you to protect them. And then, based on this, make a certain method of protection. If you implemented them correctly and took into account everything, then you can say: "Yes, I built a cryptography in the morning and it probably works and protects something." There are many examples, except for this simple cryptosystem, where it works well. For example, messaging. We all want our dialogues, our beautiful pictures of cats, when we sent them to each other, they didn't touch anyone else. The scheme of the Telegram protocol is only for an example. Honestly, I don't recommend it. It's only for example, but it shows the main idea of using encryption in messengers. In messengers, it's an

end-to-end encryption. The fact that the keys for encryption do not leave the clients, and the fact that the server is not used for data encryption. It is used simply as a mediator, as an environment for transmitting. Well, once again, MT-Proto A protocol that has some questions and some questions about Telegram. Small, but tiny. Nevertheless, it's a good idea, a good illustration of how we use encryption in messengers. A good messaging is end-to-end encrypted messaging. And you can probably name me quite a lot of end-to-end encrypted messengers. For example, Signal. OK. Triva. Okay. What's up? Yes, more? Wire, of course. More? There is a secret chat on Facebook. There is a secret chat on Telegram. Yes,

we just call them. The goal is not just to show that we are so smart and know a lot of messengers. What else do you know? Okay. By the way, about WeChat. Has anyone used WeChat? You use it all the time. As far as I know, WeChat is a Chinese product. And there is indeed end-to-end encrypted messaging. Yes, yes. Except for the chat, there is a payment system inside. Yes, but it doesn't mean that their chat is end-to-end encrypted. Okay. I just wanted to say I really don't know how VChat works, I don't call it end-to-end encrypted messaging, because it's a part of the zone that is famous for its internet interfaces. Why are there so many end-to-end encrypted messengers?

What do you think? For marketing, yes, more. The time has come. There are many messengers, but there are also many end-to-end cryptos. The first codes were used for sending messages. Messaging is a classic and intuitive example of why to encrypt data, what it gives us and what are the advantages. Messages as an application are also a great platform to build cryptography unnoticed by the user. Yes, because in many other applications, when you try to build additional security measures, you sometimes face the fact that X is limping. In messengers, this is solved much easier, intuitively clear. But your infrastructure is not only about messaging. Let me guess. Your infrastructure is not about messaging. Yes, yes. Typical abstract architecture:

client side, different client sides, middleware. How will it be in Russian? Intermediate software sounds like an intermediate layer. Ask me, I will call it middleware. You can think that it is an intermediate layer and a middleware. Typical abstract architecture: client side, middleware, database, where we store something. And of course, in our case, since we are talking about cryptography, we keep secrets in the database. We want to encrypt secrets. How can we encrypt them? We can encrypt them in the database and outside the database. If we encrypt the data in the database, what is your profit? Cool, they are encrypted there. We are great. What does it protect us from? From the fact that they will come there physically, pull

out the servers and wow! but in all places outside the base, in the server memory, on the middleware, on the client side, the data is not encrypted. We usually say that the attack surface is almost everywhere. We are not good. How to become good? In this case, everything is simple. We can move the encryption level from the base either to the middleware or to the client layer. And we will discuss these two options. I see that it is getting a little hard for you. Therefore, this cat is designed to make it easier to perceive cryptography. Look, cryptography is easy. Cats are easy. Are you ready to continue? Okay. Not ready? So. We have just talked about cryptography, we use

cryptography to narrow the attack surface. What is the attack surface, what are the cryptosystems, how can you easily and simply build cryptosystems, and that if we remove encryption from the base, then we can move it to the middleware or to the client side. Now let's talk specifically. Middleware. I know that you all work on different projects. But let's take a second for the next 10 slides. Let's imagine that you have a poor and unhappy PHP legacy web application and you need to support it. By the way, does anyone here write on PHP? Well, I'm not ashamed of one. We are sorry. In our example we will have PHP web application. It is a public web application, it is online and it

is under a lot of threats. SQL injection, code injection, execution flow changes, reflection, replay, XSS attacks. browser injections, MIT, and many more. Our poor legacy PHP applications are being tried from all sides. And we want to use it to keep secrets. But unfortunately, in this case, the attack surface is everywhere. We have to monitor all our infrastructure, monitor our poor web server. We don't want that. What should we do? Naive answer: "Let's encrypt everything, let's do it." The easiest way is to use a web server. We generate encryption keys, encrypt data symmetrically, and put encrypted data into the database. We are good at it. We get the data from the database on request, encrypt it on the web server, and give it to the client

encrypted. Cool? Cool, yes, but no. This approach has one big minus: the key to decryption is located where it is easy to get it, on the web server. If you ever faced WordPress, WordPress plugins, there is a link, for whom this world is not familiar, there is a link that describes one of the typical plugins of WordPress, which stores the key to decryption somewhere inside the plugin, with which you can easily decrypt all the data from the database. The idea of having a key to decryption of data in a place where it is easy to pull it does not provide the reliability of our system. We need to try another approach. We forgot about simple asymmetrical encryption, apparently not our case.

Let's use encryption in such a way that nothing we store on the web server will allow us to decrypt data and will not lead to the compression of this data. For example, It's very simple. We generate a random encryption key for symmetrical encryption. One thing. Then we generate a temporary pair of keys: private and public key. Then we take our data, encrypt them symmetrically with a key for symmetrical encryption. Great. We have encrypted data and one key that can be deciphered. This is not cool. We take our pair of keys, encrypt the encryption key. asymmetrically with the help of its private and public server. Thus, we get a piece of encrypted data, a piece of encrypted key for decoding data and our public server.

We send this whole structure to the database. What is the public server that we used during decoding? This is the so-called public server of the trusted decoding service. Next, it is interesting how to decode data. The data in the database is weird, it's weird encrypted. First, we need to choose what will be responsible for decoding in the infrastructure. It can be another component of Middleware, it can be proxy to database. The main idea is that this component has no public access. Decoding is quite simple. We take our whole structure, we take the encrypted key, using a private key, a decoding service, and a public server, a web service. We pull out a key for decoding data from it, a

symmetrical one, and with its help we decode our container. Voila! We give the decoded data to the client. It's easy and simple. But there is a certain feature. The proxy for decoding must be a trusted part of the infrastructure. So that we don't have access, public access to the web, to this part, We decrypt data only in the trust zone. This pattern is known to all of you. It is called separation of duties. We have separate encryption, separate encryption component, separate decryption and separate decryption component. Thus, we need to monitor and actively monitor one component of our system, the one that makes data encryption. Here we monitor it, we read all the logs, we build all the alerts, we, most importantly, look for the key storage. Who

will try to get there? In the real world, of course, this component is not the only one, because it is a single point of error. There are several physical components, and between them there is load balancing. What have we done? We narrowed the attack surface from our poor PHP web server, where the attack surface was everywhere, to one component in our infrastructure, which is data encryption. A wonderful slide that shows how good we are. From the idea of monitoring everything to the idea of monitoring Decryption Proxy. Where does it work? First, it works in infrastructure where there are already many microservices. It is already written on the microservice architecture, and we add a separate microservice for decoding and decoding. Secondly,

it works well where there is no trusted client side, where we cannot connect all these processes to the client side. These are web browsers, these are all modern IT hardware, where there is no environment for trusted code execution and, accordingly, key storage. Such a scheme is implemented in different products. There are. The first one is our open source thing - Accra Intrusion Detection System, which encrypts and decrypts data into the database. In addition, there is GreenSQL, monitoring and scaling of injection into the database. This is an open-source product of Hexa Tier. Hexa Tier has its own commercial products. Unfortunately, someone bought them, I don't remember who, and they covered their commercial line. And, of course, Oracle has a lot of

their own things about this. For example, Oracle Database Firewall, TDE, Transparent Database Encryption. I see you are tired. Tired? Tired, tired, I see. I have a cat here. While you are watching the cat, relax. Cryptography is easy. It was a simple example. Cat, cat, everything is fine. We have just talked about architecture, in which there is no trust in customers. Everyone attacks our web server, from there it is easy to steal data, to steal the key for decoding. Therefore, we have taken decoding inside the trusted zone, into a separate component, which we look at, which we monitor. But there are other types of infrastructures. For example, there are infrastructures that we can trust our clients with. What infrastructures?

mobile applications. They are considered to be more reliable than a web browser. These are hardware like TPM and HSM. Usually we can be sure that mobile applications are in the hands of the user. And very often all these mobile infrastructures are based on the idea of some cloud storage. Either OBS, or cloud servers, or cloud storage, or something else. But the idea is that You can't trust the cloud, the server. You can trust the client of the mobile phone. Here's another approach. We move our trust to the mobile phone and we build end-to-end trust between different clients. It's pretty easy when we have two users. The attack surface is basically limited by these users and their

secrets. And we've already said that there are quite a few ways to solve this. Again, in the same messaging. There is a general concept of architecture that says that we do not trust the cloud through which data is transmitted and processed. This architecture is called very simply - Zero Knowledge Architecture. Have you seen such a term before? Yes, yes, we have seen. Well, I see a couple of people nodding. "Zero-Null-Octagon" is translated as "architecture of zero-announcement". I don't know why. The special thing is that it is a design principle, an architectural pattern of design of your products. It means that all the data that comes out of the client is encrypted. And the keys for decryption are not

available to the server side or service provider. Naturally, we have already said about it. The first important point for ZKA architecture is end-to-end encrypted clients. Not thin clients, but fat clients, on which you perform cryptographic calculations. At the same time, the server does not know anything about the nature of the data. Such architectures are called "no-knowledge architectures". The second important point is that all operations are performed over encrypted data. That is, you add a new table record, you add it in encrypted form. You share data, you share it in encrypted form. You search for data, you search for encrypted data. What are the risks in this architecture? Risks arise, firstly, due to poor key control. Secondly, because of some mathematical assumptions in complex cryptographic algorithms. And

of course, because of users who constantly lose their devices. But this is our attack surface, and it is quite narrow. If you implement key management and authorization well, so that you don't have "oh-oh-oh" if a user loses his device, then the only people who you can be afraid of in these architectures are NSA, FSB, etc. Where does it work well? We've already said that it's where clients are trusted, where we can execute code on clients. We know what code is there. Mobile applications, TPM, HSM. Zerono Logic Architecture is not some new idea, it's not some super trendy hipster modern technology. It's already been decided for the majority of narrow use cases. Again, messaging. Next, authentication. We have

an interactive protocol called Zero Knowledge Proof protocols. Have you heard of it? Someone? Oh, it's a word. It was called "5 people". It's a double opt-in. Double question. At least someone. The idea of Zero Knowledge Proof protocol is that there are two sides. Each of these parties already has a pre-discovered secret. What you want to do is to compare, to find out whether the second party has a secret. At the same time, do not pass this secret on the network. The ZKP is an interactive protocol. To find out whether the owner is a different country, you ask a number of questions to each other. And on one of the questions, statistically, from 4 to 8,

you will find out with the guarantee of 99.999 that yes, it is a different country, whether the owner is a secret or not. We will not talk about the ZKP in more detail, there is a link to read it. If you are very interested in how it works, we will discuss it later. So, messaging is clear, there is a solution, and authentication is clear, there is a solution, but we mostly work with data and we want the same guarantees for our data. We want to store them in encrypted form, but at the same time it is convenient for them to be disposed of, convenient to share them, manage access and so on. What solutions are

there? Imagine that you want to share your data with several people, for example, with five people. The most obvious way is to encrypt the data with 5 different keys, distribute encrypted data and keys. Accordingly, you increase the amount of data, you get all this hemorrhoid with how to distribute these keys, and so on. And the main thing is that if you need to update the original data, then again encrypt it again, and pass it again. It sounds like zero-knowledge architecture. Well, actually, yes, it sounds like zero-knowledge architecture, because no one but clients can decrypt data. It sounds like something simple. It's not simple at all, and I don't want to do it in my infrastructures. But, as they say, "there is a leap for that" and

there is a better approach. We can break data into blocks. We need to decrypt data block by block. We are not talking about access to all data. Some people will have enough access to certain data blocks. And the main thing is that we separate data protection encryption from access control. If we change original data, we will not need to re-encrypt everything, we will need to change the access block. Moreover, it is easy to manage access revocation, it is easy to select access from those who no longer need it. The formal mathematical model of this approach is described in the paper on eACR. I will tell you how it works very simply. First, the storage keys are kept

encrypted with access keys. So we have two different key levels, and there is access to storage. This allows to control that only trusted users can change the stored keys, comparing ownership tags. In fact, this is a two-way evidence, this is a comparison of authenticated Macs. So, let's go further. Next, we have separate access keys. We need to make sure that no one has the right to go to the data, has no right to put plain text into the data, into the bypass of our crypto core. Because if with such architecture, manage privileges, if with such architecture someone has the opportunity to put plain text, then someone will have the opportunity to read plain text. In Zero Knowledge Architectures, the main rule is no plain text in

the database. Such approach can be used everywhere and can be found everywhere. These are large documents with granular access. These are huge spreadsheets that you don't want to share completely, and some of them you want to share with the manager, some with the accountant, and some with a young student. Of course, these are databases. But when we talk about databases and when we talk about ACL in databases, we always remember that when we get root access to the server, we can modify everything we want with our… We do privilege escalation and can modify what happens with the data. If we protect access to data cryptographically using keys, just hacking the server will not help us. Where can this be found? It's already

made for you, it's already done before you. Where can you find it? Where is the illustration of Zero Knowledge Architecture approach? The first one, probably, let it be the last one, is LAFS - List Authority File System. It's a distributed data storage system that divides data into pieces and stores your data in pieces, encrypted, and stores them on different servers. The second one is ZeroKit. ZeroKit is a system for for distributed storage, they also have integration with Apple CareKit, that is, they are perfect for medical data. And the first is the open source crypto framework Hermes, which is designed to solve the problem of access control to a large number of data that should not be visible to everyone. For example, these are medical records. Yes,

here is a granular access to data for different people. Why did we need all this? We remember, we come back, we come back. Why did we need all this? Because we are leaving the idea of attack surface everywhere to the idea that we give trust to the client side and we monitor the client side. And if we did end-to-end encryption, if we did not impose keys in the management, our attack surface is quite narrow. I see that you are tired, but I don't have slides with cats anymore. But there are a couple of slides, it will be fun. What we did in these two mental exercises? We tried to narrow the attack surface for different

architectures. So that when you think: "Why do I need cryptography?" What should I do? What is properly implemented cryptography? How to determine what is properly implemented for my specific use case? In addition, of course, to a whole bunch of cryptographic requirements. The answer is very simple. Properly implemented cryptography for your infrastructure gives you control over the attack surface, over your protected data. Depending on the type of architecture, you need to use certain schemes to manage the encryption scheme. There is another cool idea that I like very much, it's called echelonization. It's from the French word "echelon". You probably know, right? "Echelon" is a military structure, whatever it is. For us, it means that if the system has only one protected perimeter, then

whatever it is, No matter how we think that this is a great protection system and no one will break it, sooner or later it will happen. The idea of ​​shelanization tells us that each layer of the system must have its own protection. All these protections must be connected so that trust and threats are calculated for each layer and for the system as a whole. There is no cat, there is a crocodile. The crocodile says: "You just don't have enough cryptography." And it brings us back to another slide with key takeaways. What is "slowness" for us? Obviously, it's not castles, not ditches, not crocodiles. For us, it means that in addition to cryptography, in our complex super systems, We still need all these boring

traditional methods, which everyone knows already. This is monitoring, logging, key control, detection of invasions based on rules, based on training. This is access control. This is everything related to access, including access revocation, which everyone forgets. Also firewalls, tunnels, this is all that needs to be applied to each point of attack. on your attack surface to your data. I really like this slide, it's my new favorite slide, I've probably already shown it, maybe some of you have already seen it. About a year ago, these authors published a great study. They studied about 300 different vulnerabilities in different applications. And they divided the causes of vulnerability into two large groups. The first vulnerability was caused by the bugs in the crypto libraries and the

second one was caused by the bugs in the use of the crypto libraries by the authors of the applications. What do you think, what are the percentages? Let's guess the first number. How many percent of the vulnerability was caused by the bugs in the crypto libraries? 4, 10, 20, 20, 40, 4, 42. But in general, 20% was the closest. Only 17% of bugs that led to vulnerabilities in applications were related to the inside of crypto libraries. The rest, the majority, was related to these hands that these crypto libraries integrated into their wonderful applications. I'm sure you wouldn't want to be part of this statistics. And the first thing too. If you don't want to be part of this statistics,

Use cryptography very carefully. So, the penultimate question. Attention question. What have we mentioned twice? Yay, a cat! Okay, okay, good. It was a report about cryptography. Except for cats, what have we mentioned twice? Zero knowledge. A little more abstract. Closing the... Raise your hand, someone said "Yay!" We did two mental exercises for two types of different architectures with two different sources of trust and chose different methods to narrow the attack surface. Right? And there were two slides with cats. I hope they helped you. So, the things that I hope you will remember when you go there, the main thing is to go there later. What is it all about? It is about the fact that every complex

cryptosystem is designed to narrow the attack surface. Not to say: "Wow, we are good at encryption!" No. Depending on the processes you protect, depending on the trust in various components of your system, you choose which schemes You need encryption. Not just algorithms, but trust schemes, key control schemes. We touched on two of them. We put trust on the client's side in one of the schemes and built an end-to-end encryption system, where they trusted the whole server side with zero knowledge. The second example was that we put trust on middleware, developed encryption and decryption in different ways. different components and said that whatever happens to the client is a problem for the client, we do not trust him. Well done! In addition, there

is a useful remark that you already know, do not write your own crypto algorithms yourself, use the Resolute Facet. Naturally, I know that in the beautiful spring time you like to read cryptographic books, so I prepared a few links, if you are interested, there are interesting and fascinating articles. If you like to watch reports, there are some links here as well. We will post it somewhere. It's encrypted. No, it won't be encrypted. That's it. This is the penultimate slide. If you have any questions, firstly, thank you. Secondly, if you have any questions. I see your hand.

Hi, thank you for the presentation. I have a very difficult question. Every time I do a project, my encryption is based on the fact that I need to search for user data. If the search doesn't go into the client, when I can search and filter everything on the client, it's not clear how to do it. Are there any ready-made solutions for this? I was looking at homomorph encryption, but it seems to be not working very well. You've outlined the problem. What are the solutions? First, don't look for the data you encrypt. It depends on what data you have, what data flow you have. Perhaps the data you are looking for, you don't need to encrypt. Or you don't need to

search for them. It depends on your architecture. And the second one, if you need it. There is homomorph encryption, it's not super-duper. There is also symmetric searchable crypto. From the point of view of algorithms, there are libraries. Is it fast, convenient, simple and understandable? No. Any other questions? Another question about generation of really random encryption keys at the initial stage. Usually, they use KDEF, KDE derivation function. I see you are shaking your head. Please, pass the microphone to… Let's listen to the doctor who is shaking his head. Key derivation function is not about that. It is a derivation of a key using some PBCodeF2 algorithm from a user key, from a password. And the person asked about the generation of pseudo-accidental data, about PRNG functions. That is, where

to get a source of really relative accidental data. Okay, good. Let's divide the question into two. If the question is really where to get an accidental number, then? There are two answers: the first one is bad and the second one is cryptographic. The first one is bad, we take the RAND function in those languages and frameworks we work with. Why is it bad? Because it's not cryptographic-resistant way to get random numbers. If you read the first chapter of this book about serious cryptography, it's all about random numbers. The second answer is that we use random sources in libraries intended for this purpose. Correct me if I'm wrong, but OpenSSL, which is not a standard, has a

random, which is not a standard. Yes, you mentioned TPM and HSM, they are engaged in this, as far as I know. Yes, if we go to the hardware area, yes, of course, there are TPM and HSM, but they use several sources as an entropy source, as all built, as an entropy source, they use several sources. To minimize the possibility of attack. Yes, if we talk about software level, if we don't have the possibility of TP, MF, HSM, then, say, OpenSSL. Is there a random source in OpenSSL that is not a standard?

Yes, there is. NIST decided that DevU Random in Linux, when correctly assembled in Linux, is good enough to provide enough entropy in consumer applications. If NIST decided so, it's good enough for almost everyone, except those who are not CMSA. So, answering your question again. You can use a regular RAND in a regular language. It will not be considered as a random number from the cryptography point of view. Do not use it for passwords and so on. If you have the opportunity to use TPM, HSM, use them as a random source. If you are limited only to software, use cryptographic libraries. What? Blockchain? So, be quiet about blockchain. Use cryptographic libraries that are approved by NIST, for example, OpenSSL.

What is blockchain? Blockchain as a source of entropy. I feel the report. There are elements of academic courses, including cryptocurrencies, and there are a number of studies that measure entropy generated by people. during the construction of blockchain. Yes, in entropy generated by people there is a problem. So people are dumb enough to consider it a random process? There is a problem with that. And then key derivation? You need a random number when you need it, and not when a person is dumb enough to consider it random. Volodymyr Sergeevich, I support Anastasia. Please prepare a report for the next B-Sides. Okay, another question. Yes, I see the hand. Excuse me, please raise your hand if you have any more questions. There will be

one more question later. Thank you. I have a question. You can encrypt everything with different algorithms, with different key length, and it all takes time. How to find the balance between productivity and security? What questions should we ask ourselves? How much money will you lose when… when everything is going to flow. Actually, you can go deep into this hole for a long time. There is no super checklist that you can understand: "I did it, I did it". Because there is always a step that you can do more and more and more. From the point of view of business, there is an idea of some common sense, when the amount of money that you invest in your protection system, It's much more than the

data stream. You will lose much more. Secondly, there are regulations. GDPR, PCI, DSS, HIPAA. There are regulations that require at least some minimum. Thirdly, depending on your subject area, how do you work? If it is some data that can directly harm other people, what HIPAA says, medical data, plus data that you can use to cut cars, probably these are areas with increased attention and you need to go deeper there. But if you can't answer this question yourself, the idea is very bad, hire those who can. Thank you very much. Yes, I have a question about the protection of our poor PHP server. Poor server, I can feel it. What is the point here? We can configure a server for processing that will

be a broker of encryption to the database. But if we had a breakdown of about HTTP server breakdown, we can send a malicious code to our clients, which will force them to decode the server data and force them to run somewhere. How to decide? I'm sorry, I was looking for a cat, I missed the thread of the question. But if I heard, we allow clients to decode data. When we allow clients to decode data, we trust them. In case of web, we don't really want to trust them. We don't let our client to encrypt. Yes, once again. We have PHP server, which unfortunately was broken. And accordingly, we can, from the point of view of attacker, he can force the encryption broker to just

pull out all the information. So, you have a thing that decrypts data. What pulls the information? These are requests to the database. For example, there is a MySQL injection, select *. It goes through some service. In our case, it went through the decryption proxy. Why? Because the decryption proxy entered the data, took the data encrypted from the database, decrypted and passed it back. This is the place where you can monitor all the behavior of your system. If you set it up, if you have some kind of intrusion detection, you set it up, but the fact that it's a select *, probably, it's not worth going to the database with this and returning something. You're doing well. If you didn't set it up, well... Well, yes. But again, the problem

is, if, for example, an evil person installs a program that will merge all the information in a little bit, it's... As it is requested, it is used by the user. At the same time, they can be used to merge all this information. The encrypted one? It decrypts before sending it to the client. But we are monitoring the place that decrypts. If you don't monitor it, then… We monitor the place that decrypts. It transmits to… - They are already decrypted. - Yes, and at this moment he can delete all the information. - He can. - Okay, no problem. Dasha, I see one more hand. I think Evgeny wants to get into our conversation. - Traditionally, this problem sounds

like this: if the attacker is able to emulate behavior that is not different from normal, and even if it's not heard. If I heard correctly, we are talking about whether we can say that the client's behavior is predictable and correct or unpredictable and it seems to look malicious. Machine learning. So, if we are able to distinguish it in our system, then we can react to it. How to distinguish it? We analyze logs, we analyze the behavior of the client. If we have an intrusion detection for this, we can say that something is wrong. If we don't have anything of this, then yes, of course, anyone can merge our data in plain text and we won't say anything about it. Do we want to continue or Yes,

of course. Wait, microphone, microphone, microphone. I don't know how correct it will be. We'll put some NetFlow analyzer in the cut, feed it all. Of course. And we'll look at it. And plus IPS, IDS, and some cheap… Well, snort, screw it, and that's it. Do you know who to contact? No, no, no. Too late, too late. Do we have any more questions? Thank you very much. I think we have a maximum of… No, there was a question. It was very… earlier. This will probably be the last question, okay? To continue what you said about entropy characteristics. There are a number of cases when it is difficult to generate an adequate flow of random numbers, but at the same time, for example, there is a web, the same IOT. Are

there any services that provide quality flow? Yes, Entropi as a service. The question is: Have you heard about Entropi as a service? I have. There was a girl who threw dice, cubes and sent I know that Cloudflare has lava lamps. Does anyone else know about the service? I see hands behind, but they need to be carried by a microphone. We agreed that this will be the last question.

There is also random.org. As I understand, they have hardware devices, which they use to calculate entropy. And you can get it for free through API. Okay, there is another option. I see another hand. We have blitzviktorina. There are a couple of normal commercial enterprise services. The main problem is whether you trust this service and whether you trust the connection between you. At the moment when your source of entropy is far from you, in fact, the security of the system is reduced not to the quality of the source of entropy, but to the trust in it and the connection. Good comment, thank you. And now I see the last hand, you add about the source of entropy, right? I don't remember the site, but

when I was disassembling I had to find the wallet that I needed. I lost it. I looked in the opposite direction and found a service that generates a lot of wallets based on your private key. And from there you can also get a piece. I think it's not quite right. But it's a thought. Okay, I'll write it down later. Let's talk about it in more detail later. Thank you very much. It was very nice to tell you about cryptography.