 Yeah, I'm having this talk in English. I hope there's nobody who expected it in German. Yeah. I want to talk a bit about own cloud and the encryption module in it, but it's more like I want to talk about crypto design in general. And this is just an example. What I'm looking at here, but it's the message is much more general. It's not I mean, this the bug I'm going to show you is not, I think it doesn't have a very high impact, but it tells you a lot about how to design a crypto system. A quick introduction about me. I'm Hanno Burke. I work part time as a freelance journalist. You may occasionally read my articles on Golem. And I also do a fuzzing, which is supported by the Linux Foundation's core infrastructure initiative. And yeah, I had to talk about that earlier today. And occasionally, but this is just like my private interest. I do things with crypto. And I hope you all have heard this in one way or another that if you do crypto, what you should never do is inventing your own crypto algorithms. Like if you think you invented a super secure cypher that nobody can break, then it's probably not very secure. But I want to ask you a bit like how do exactly do we interpret that rule? Because I think there are some subtleties that are not entirely clear. And I mean, this is an obvious example. This came up on the IETF crypto working group list, where someone presented a new cypher, the crystalline cypher. And there are a number of things like, yeah, it's designed to be as secure as a one time pet. That's usually already a sign that something might be strange. Yeah, random sources based upon radioactive decay. Okay, maybe a bit complicated in your smartphone hopes to set a new standard in security. And then the key sizes 16 kilobyte keys and salt. That's I think 128 kilobytes. And you should get them from a truly random source. And you can if you don't know where to get your randomness, he has a URL where you can download your randomness. So this, I mean, this is obvious. Yeah, that's not a serious project. That's it. But you have these people come up every now and then on on some crypto mailing list, someone comes with Oh, I have invented a new cypher. And then like people point out some obvious flaws, and then they don't understand it. And okay, that's not how we do crypto. But that's another thing. And that's like, okay, we all know we should use standard algorithms, we should use algorithms that a lot of people have looked at, like, for example, AES or RSA or chart 256. But the problem is, even if you use these secure algorithms and put them together into some kind of protocol, that doesn't automatically make a secure protocol. Like, we learned a lot in the past decades about how to put together things and get a bad protocol like SSL version three SSL version three. The building blocks are mostly quite okay. It uses RSA, you can use it with AES or triple this, that are all secure algorithms, but the whole protocol together. There are many subtleties like how do you do padding, what kind of modes are you using from those cyphers. So I would say we need to interpret this rule in a way that you should not build your own crypto algorithms, but you also should not build your own crypto protocols, at least not if you don't know what you're doing. Yeah, and that brings me to own cloud. Now, this catch my interest. This was a press release. They later removed it from their web page, but there was luckily a Reuters news message, which reproduced this press release, where they say, okay, they have an encryption module. And this modular approach, you can swap out the existing AES 256 encryption with the new RSA algorithm. RSA is from the 1970s, I think, and AES is from 2001. So also, I mean, RSA and AES are very different algorithms. RSA is a public key algorithm and AES is a symmetric algorithm. So this doesn't make a lot of sense to swap them out. So, okay, we know on cloud has written a press release, obviously, by someone who doesn't know a lot about crypto. And that kind of got me interested in looking at what this encryption module actually does. So to understand here is what what this module does is maybe not one what one would expect. So the threat model is a bit unusual. The idea is you have own cloud installed on one server. And you trust that server. But you include some storage space, maybe from some cloud provider or something that you embed. And and you don't trust that storage space. For example, if you want to upload very big files, you don't have enough space on your web server. And then you have some external web space that you don't trust. And so you use encryption. And your keys are on the server where your own cloud itself runs. But the files should be safe on some some potentially untrusted storage space. So I I'd like to say, okay, there are probably not a lot of people who need this scenario. So I assume this is probably not used by a whole lot of people. So I think the the vulnerability I'm going to show you is not that big of a deal. But yeah, as I said, I want that you learn something about crypto. So so the first thing I did is just looked how do these encrypted files look like what's in them. And they start with this text, which says something H begin something about encryption module. And now we have a problem with the screen resolution. The thing on the right is AES. And then 256 CFP. Okay, so we know something about the cipher they are using they're using AES and they're using it in CFP mode. So we have to learn a bit about modes. So AES is a block cipher. That means you have a block of which is for AES 128 bits. And you only encrypt the block. So the algorithm that you're using is 128 bits. And you only encrypt the block. So the algorithm itself, you cannot say, please encrypt this text, you can only encrypt a block. So if you want to use AES in practice, you need some kind of mode to use this block cipher for longer inputs. And there are different kind of modes. ECB. So ECB is basically just encrypt one block by another. And this is not really an encryption mode. This is totally insecure. You should just never use that. It's more or less just an example to explain block modes. Then they're quite common modes are CBC and CTR. They are, for example, used in CBC is still used quite a lot in TLS. Although it probably shouldn't be used. And CTR is in more modern products. These modes only encrypt something, but they don't guarantee you that that any authenticity. That means if an attacker can manipulate your cipher text, he may be able to change it in a and change it in a specific way that like flipping a bit, things like that. So you flip a bit in the cipher text and the bit gets also flipped in the decrypted text. And then there are modes like GCM or Poly1305 or OCB. These are so-called authenticated encryption or more detailed authenticated encryption with additional data. And these modes also guarantee you that unless you have the secret key, you cannot change the content. So if you change something, then the recipient of the message will notice it. The algorithm will just say, OK, here happened an error. This cipher text is not correct. And then there are some special modes for hard disk encryption, which is a bit messy, but that's not the topic today. And as a rule of thumb, you can say usually you want to use authenticated encryption. There's almost never a good reason not to use authenticated encryption. So what's the CFP mode? So it's a bit more unusual. It's not a very common mode. The feature of CFP mode is that it's self-correcting, that if you you can start the decryption in the middle of a cipher text and then you get one bad block and the next block is correct again. So what this enables is that you can do things like seeking. I only want to download the middle of a file or just the second half or things like that. And it's not authenticated. You can flip a bit in the cipher text. And what happens then is that this bit will be flipped in the decrypted text and it will change the next block to something basically random. So as an attacker, okay, we cannot decrypt the cipher text, but we can change the content. And so okay, how does this matter? Now let's assume someone has an own cloud instance and they are uploading some piece of software for their colleagues, like an installer or just a small exefile. Then can we maybe backdoor that exefile if we're an attacker that can access this space? Now if we look at an exefile, you will see this program cannot be run in DOS mode. So even on modern systems, every Windows executable still has a DOS program embedded that usually just displays this text. And the interesting thing is that this is always the same. At least if you're using a standard Microsoft compiler. So we have something here, even if we don't know what this exefile does, we have some some bytes here where we know what they are doing or where we know what they are. So we can manipulate them, maybe in the way we want. And this is yeah, I created a proof of concept here. So we can just yeah, and another thing is like the in the fourth line, there's this 001000. This is the offset of the Windows executable header. And so what Windows does is it checks this offset if there's a PE header, which is like the modern Excel header. And if it's not there, then it assumes it's a DOS program. So okay, what we could do here is and what I did to proof of concept is that if you just and yeah, and also for the block length, the block length is exactly one line here. It's 128 bits, which is 16 bytes, which is exactly one line here. So if we change anything in the third line, then this will scramble the fourth line. Because we had CFP mode, you change something next block has random content. So if we change a single bit in the third line, the the offset of the windows PE header will be destroyed. And it will be a DOS program for Windows. And in the fifth line, this this step DOS program is always the same. So we can change that at least we can change one block of it. Now. Yeah, that's what I did and created a proof of concept code. So you're just flipping one bit in the third block, then you're X oring this DOS stop code with the code you want to inject. And then your X or the cipher text with it. And then, yeah, we have changed the executable to execute some code that we want. Now I have a demo for this. Here's an own cloud instance. And way upload some I wanted to have a I had a putty executable prepared here. We'll just download putty then I'm just using putty because it's a small executable. And yeah, I want to start it. Okay, and now now we we look on this server storage space. Now we have the directory for the user admin. And we have the putty exit here. Now the first interesting thing is the file name is is still the same. So we're already leaking some information to our tech. Okay, better. Yeah, and if you look into it, as we saw before this age begin and own cloud encryption module stuff. And now we run this exploit code on putty exit. Okay, so we yeah. And now we downloaded again. Yes, a file. Now this so the putty access the one we had before and the putty one access the one we just downloaded. And so if we start the original with dustbox because it's now a dust executable, it will say, okay, this cannot be run in dust mode. And if we start the manipulated one. Okay, it principle. So that's on the screen, right? Yeah, so what we did was yeah, we we had an executable online and we could inject some code under our control. Now this is only 16 bytes of code that doesn't really give us a whole lot. But we will find other places in the executable that usually have zeros or have other stuff that we can predict. And then we can jump around and backdoor many parts of the file. So this is definitely possible to create something exploitable here. Yeah, then I reported this to own cloud. The first fix they proposed was that they were now using counter mode. And they are so they are always encrypting blocks of eight kilobytes, and then use an HMAC authentication. This is better, but it still has a problem that you can still swap around the blocks inside a file because every block is is encrypted in the same way. And still the problem that the file names are leaked is still there. Then then the second fix they deployed is that they they embedded a number for the block. So now you can no longer swap blocks around the file name leak is still there. This is what they shipped in version nine, which was recently released. And now you might ask is this secure and I can just say I don't know it's secure enough that I did not find anything obvious in it anymore. But I'm yeah, I know a bit about crypto, but I'm not like an expert to audit these kinds of things. So in my opinion, this module either should get a professional audit from someone who knows this stuff. And I mean, also, there are other potential issues like how do they generate their keys? And does this office key storage make sense? Either this needs a professional audit or the module should be removed. That's what I said told the on cloud developers. Obviously, they decided otherwise, they ship this now, maybe fixed version. I don't know if it's secure. Yeah, then you might wonder why don't they use authenticated encryption? That's also what I asked like, just use GCM. I mean, GCM is it's not perfect, but it's definitely better than building your own combination of various modes. The problem with that is that on cloud is written in PHP and PHP doesn't support GCM mode. So you currently cannot use authenticated encryption modes from PHP. They plan to change that in PHP 7.1. The problem with that is, then you can maybe use it in 15 years because people tend to use PHP versions which are 10 years older. I don't know. I think the most common PHP version is still 5.3, which, I mean, 5.4 is already out of security support. Yeah. Yeah, maybe. I mean, PHP 7.1 is not released yet. So I think it will be released in summer. Then, okay, you might, how would you do better? What would I propose? And it's a bit difficult because for this scenario, I think there's no ready-made protocol or construction that you can easily use. And I think this is a problem. There should be something like I want to encrypt a file and store it somewhere with a key that is a pretty standard scenario, but there's no really good solution for it. And you solve some problems if you just use authenticated encryption. But then if you want to start, I want to be able to download a part of a file, then you need to chunk that. And this chunking, there's no standard for it. And authenticated encryption also has some traps where you have to get things right. So I think this is really a lack of some kind of protocol or standard for this use scenario. I thought about one possibility, but I'm not sure if I would recommend it, but I will present it anyway. I thought, okay, we have standards for message encryption like for emails like PGP or CMS, which is as my technology. We could say, okay, we use that. I mean, this is with public key cryptography, but we could say, okay, let's use a public key cryptography. It's lower than the symmetric key, but maybe that we don't care. We just want something secure. And this is maybe well audited. But then I looked how what I do cryptographic message syntax in PHP. And in the documentation, this was the example. And it's using RC two with 40 bits. Yeah, that's kind of yeah, export mode crypto history from the 90s. So it's also not straightforward to get this secure. So and I don't know if this is a good idea for this scenario. So but yeah. Yeah, so takeaways. Don't invent your own crypto. Don't invent crypto algorithms. Don't invent crypto protocols. Authenticated encryption should be used usually whenever possible. And unless there's a very good reason not to do, that's the way to do it. And I think we lack some proper standards for these kinds of use scenarios. Although it's I think quite a common thing. There's no standard solution where you can say here put in your key here put in your thing to encrypt. That's something that should be there and isn't there. And yeah, you probably should not trust the own cloud encryption module. Yeah. Thanks. Are there questions? I'm just asking about your opinion. Do you consider NGFS or eCrypt FS for this use case as a better alternative? Um, what was the first one? It was it's just one question. Do you consider? Yeah, I didn't understand the first one. So it was just this question. Yeah, do you consider NGFS or eCrypt FS as a good alternative? I don't know the first one. I know eCrypt FS. But the problem is that these disk encryption things. They do a lot of tradeoffs between security and practicality. And it's not really nice what they're using either as encryption modes. So it's probably not a good alternative either. Okay. And also, I mean, this is probably not available in PHP to include in a web application. And yeah, I mean, you're laughing, but I think I mean, PHP, whether you like it or not, it's a standard programming language that's used for a lot of applications. And I think there should be encryption technology that's just usable and works. I think the the scenario that when you're looking at clouds, having this you don't trust is not that exotic. So it says something you would recommend. Actually, if you you have rented space somewhere in the cloud and you don't want I mean, it depends what you want to do. If I know that there are like backup solutions that encrypt like attic and stuff, but that depends if that matches your use case, because that's not a web application. So yeah, but I don't have a good recommendation. Okay. Yeah, thanks.