It looks like you're having connection troubles. Reconnect now.
01/12/2021 12:55:46
33c3-talk-8014 Latest text of pad 33c3-talk-8014 Saved Jan 12, 2021 |
Hallo Du!
Bevor du loslegst den Talk zu transkribieren, sieh dir bitte noch einmal unseren Style Guide an: https://wiki.c3subtitles.de/de:styleguide. Solltest du Fragen haben, dann kannst du uns gerne direkt fragen oder unter https://webirc.hackint.org/#irc://hackint.org/#subtitles erreichen.
Bitte vergiss nicht deinen Fortschritt im Fortschrittsbalken auf der Seite des Talks einzutragen.
Vielen Dank für dein Engagement!
Hey you!
Prior to transcribing, please look at your style guide: https://wiki.c3subtitles.de/en:styleguide. If you have some questions you can either ask us personally or write us at https://webirc.hackint.org/#irc://hackint.org/#subtitles.
Please don't forget to mark your progress in the progress bar at the talk's website.
Thank you very much for your commitment!
======================================================================
I'm going to talk to you about an idea, arhats on how we can kind of regain a little bit of trust in the everyday computers we use. So what is the problem? Well, the problem is basically these guys I mean, the thing is, like we all use computers in our lives. We use them for like I don't know what use them for, but I use the most important thing I think I'm doing with my computer is actually talking to other people. I mean, yes, we are all watching videos, but, you know, talking to other people. And we do have quite a problem there because even though we have developed quite a lot of solutions to make this talking to other people more secure and to actually hide from these guys what we are talking about, like all of these solutions, like, for example, or TIAR or signal, like executing in. A like basically this so this is a block diagram of a modern computer, in this case the Lenovo Extra 30 I'm using to show this presentation to you. It's a kind of three year old or something laptop based on an Intel CPU. And like as you can see from this block diagram, the thing is super complex. And the thing is that on this machine, I'm executing my GPG and everything is encrypted and everything is fine. The only problem is like the plain text of my emails, which I'm decrypting, even if I'm using something like a smart card, it's going all over the place. So A we have like a super complex system. We have like also in this case, the red highlighted things are like subsystems that contain some form of proprietary firmware, which we cannot audit. And all of this makes. I would say pretty easy for a sufficiently well-funded attacker to actually attack that system. So now, if we want to consider this system and like what we ultimately want from it, I mean, ultimately, I want to talk to my friend about computers because I like computers and I generally use a keyboard to like type stuff. And then I click send and then get send and encrypted and decrypted. And on the other end it's displ
ayed on a screen as worts and my friend reads it. Now, the thing is that as you can see from my plot diagram of highlighted, like the parts that I like, I actually need for that communication and green like keyboard and display. Um. If we say that, OK, at the display and at the keyboard, I basically need to use plaintext because Krypto glasses are not you have to think. And also I cannot really type in hours or something. So in the end, I kind of need to have plaintext there. But on the other hand, I don't really want to trust all of that other stuff, especially like these things running unflustered firmware, like the things we've read. What is the problem in that case? It's like since a couple of years now, Intel has gifted us something, namely CPU's and basically the platform controller, which is containing the integrated graphics, which are both running proprietary, a pretty robust engineering resistant firmware. So I have to use this CPU. I kind of need that because I want to encrypt stuff and decrypt stuff, but I don't really want that thing to be handling plaintext. But on the other hand, like, I have no choice because there you see all the arrows are pointing to it. There's no way, no way around it. So we need to like, think about where can we place that kind of trust boundary. And I think realistically, there's really only one choice, and that is basically to place this trust boundary like up to where do I want my plaintext to be and where do I want my ciphertext to start right at the input and output devices. Because realistically, I don't think there's a really high chance that we will be like reverse engineering into management engine and then better control of firmware for any any for any practical number of platforms and keep it open for any number of years. So the places where we need to put this kind of encryption or something that makes it happen is a in the display plus or display busses and the laptop. That's primarily a Alvidrez bus, which is a di
gital display based on more modern devices you would use and better display port, which is basically very similar to everyday, just with added protocol layers. It's like very high speed, but it's just plain pixel data. So there's not much encoding happening there, no video codecs or anything like that. And on the keyboard side of things, that is basically the and that is like this laptop. And I think most of our lenno devices, the embedded controller, which is some kind of management thing, which is doing basically everything that couldn't fit somewhere else, is basically scanning the keyboard continuously. And the keyboard is just really a dumb matrix of switches. So pretty much no active devices there except for a couple of LAT's for like muite and polla. So from this point of view, we need something in between of these components that will be receiving hopefully only unflustered ciphertext from klavern controller Hape, which contains the integrated graphics and the embedded controller, which contains the basic keyboard, keyboard, matrix scanning and forword like do some decryption there and encryption on the reverse path and forward that to display and keyboard, which fortunately are pretty simple devices. So there's not much logic happening in there yet if we ignore and but at this report and so on. So the thing is now if we look at that looked like CPU and better controller platform controller hub, the intercept to display keyboard and these two pretty simple basses. That has a nice side effect of implementing a system that way, and that is that these two simple busses are used pretty widely. For example, this is a block diagram of what's in this case. Texas Instruments would like your smartphone to look like it's pretty much the same for the windows. They basically just exchange, like who makes the parts. They all do this basically the same thing you have, like the CPU in the middle of this application processor, which in fact it's a huge system on a chip like
modern ones even include like packet switched memory boxes and stuff like that's a really advanced stuff. But in the end, that thing is only talking to your display via something very similar to Alvidrez. Some are even using embedded display port. So like a high speed protocol, but still pretty dumb. And I mean, you don't have a keyboard and most smartphones, but you have like touchscreen. And these touch screens are generally also controlled over like a simple super protocol, like ICSE. So we can definitely adapt the solution from before to also work. In a case like this, you will obviously have like poor management issues and form factor issues, but. Purely technically, from the electronic and computer science side of things, this should work. Um, so if we look at this block diagram of of this general idea on how we could organize all computers, we have this intercept device. So it needs to kind of do something with words like receive that process and send it back out and do something with the keyboard switch matrix scanning. Like how does this like how how would you actually control that from an application point of view from software running on the host machine? Um, basically this is the general idea I have for that. This is a diagram of what a frame sends from a basically basically any moniteau standard today. Looks like you have like this vertical and horizontal sync signals, which basically are framing information stemming from back when Vijay was a thing. And then you have like the actual content area, the where most of the time you have some kind of desktop desktop environment running and then you have like a application window inside that desktop, which may contain something worth protecting. As an example, think, for example, of Thunderbirds, where you want where I want to send encrypted email to my friend or I want to receive an encrypted email from my friend. So in that case, Thunderbird is like running on my Linux system, displaying a window. So if I'
m receiving an encrypted email, that window is displaying, like basically if I would not have like an e-mail or something installed, it would basically display ASCII Ahmad GBG Binary. Now, what we need to do in this to make this work in this scenario is we have some kind of add on which which recognizes that I'm just playing like GBG Armored cipherText and which will take this Fujiyama like convert it back to binary form and then formatted it as a simple bitmap, a bitmap that contains a special header at the front that tells the intercept a device something like the width and half a height of the bitmap and contains a authentication code. So I can't just cannot just anybody go and a business which would work with my incepted device. And then I need to display that bitmap, which fortunately I can do on basically any operating system, any platform. And this bitmap is then interpreted by the interceptor and decrypted on the fly with the intercept. Since it has access to the keyboard and this may ask me to input a passphrase or two, I don't know, insert a smartcard or something depending on the implementation. And the decrypted plaintext is then rendered into a pixel buffer which is inserted in the life display data stream, basically at the same place where this payload was communicated before. So basically, if I'm running Thunderbird, I would make this. And also the entire window where I'm reading my email would be this payload area and containing the ciphertext. And this interceptor would exchange that by the decrypted data in flight. Now, how would you actually make that work? The thing is, this interceptor needs to be able to process this really high speed display, places like Elwood's and do like in-flight transformation on it. So that's a pretty hard task. And also we want it to be like somewhat not too complex so we can actually secure the thing itself. So we don't just replace like one huge attack surface with another huge attack surface. Now, the like, to me, t
he most obvious way to do a way to do this would be to use an FPGA for most of stuff, because these things are basically very nicely suited for this application, because they're really good at handling large bandwidth, high bandwidth, high frequency data like and display bars. And yeah, this is basically how I would imagine a such an FPGA based interceptor to work. By the way, sorry for the non-plan on graphing. So like without looking too much into it, we can already see that we have an advantage against like this eighty six, uh, platform like Vilanova X to thirty here in that we have like we do still have a lot of components, but they are not like that, they are not that centralized. There is like some some factor of combat combat compartmentalization there. So I have, for example, a I will for example, if you consider the display data path, if my display signal does not contain any payload, any headers, any special markers, and it's just regular display data, then it will like it will go in. This diagram would go up, go in on the bottom right side, which is basically the from the untrusted domain, from the platform controller up on into platforms, it will go through a Ovid's serializer, which spacer converts it into a smaller frequency, lower frequency signal for F.J. internal use that would go into a pattern detector. Now, if that pattern detector does not detect like this special mocha header I put in front of my jpg payload, it will not do anything. It will just pass on the signal. The signal will then go through a frame buffer for like Klok reasons. Then it will go through a buffer switch, which in this case also does nothing because there's no payload there. So there's nothing to replace. And then back to serializer. And the interesting thing is that at no point this high bandwidth display data signal, which may contain like other sensitive information, I don't want the interceptor to know. At no point does it even touch anything. Apart from some relatively
simple parts of like digital logic, so that it's not going through any kind of CPU or higher level processing, it's basically just a bunch of schist registers, pattern matching and a couple of Paphos. So in this way, I can organize the system. So that's like sensitive data is really only touching parts that absolutely needs to touch, like from an electrical point of view. This like on the Fuge separate busses for this kind of data. And this way I can kind of reduce the attack surface of that somehow somewhat. So let's consider now the case of a frame that contains actual encrypted payload data. Now, the key for this data is in the like, depending on the implementation, even the FPGA itself or in a external access module. So basically the smart card and the CPU and graphics processor, which format of that data for me do not know that key. So that can decrypt it. They are just running a basically a bitmap graphic and now the pattern detector and this device will, when it's receiving this data, recognize that header which was previously formatted and that it will go on and write the payload. In this case, like the A probably probably some lightweight protocol and then the actual JPEG data into a payload Tafa. And upon completion, it will notify something I called the application processor because basically I think you will probably need something like that. And this application processor will then do processing on that. Like, in fact, what it will do in the case is it will probably do some protocol decoding, then extract the actual cryptographic payload, send that onto the to a Cryptochrome processor. I think it makes sense to distinguish these two things here because A, the application process, like for most things you don't need like any kind of cryptographic acceleration. And on the other hand, maybe you don't want the thing that is handling all the complex protocol logic to actually also do the encryption, decryption and handling of plaintext. And this Cryptochrome
processor would then decrypt this payload, possibly with the help of a smart card, secure access module, and then for the plaintext via a separate data path to the renderer. So physically, the application processor in this scenario would never be in possession of a plain text. So even if you compromise it through some way, some means you would not be able to access plaintext data there. And the render would be a piece of basically prolly another processor realistically probably running something like free type that is converting like UTF eight inputs into pixel data, which as it turns out is a really complex problem. But I will be coming back to that later. And this renderer is then outputting a bitmap and to render buffer and this render buffer is then dynamically switched into the inflight leader. So I am at a display signal by this uSwitch thing. So the buffer switch basically just needs like the position where to flip between upstream display content and the above and into account the position and X and Y coordinates and then switch over and switch back. Now, the nice thing about like this entire compartmentalization thing is that it enables also some kind of some neat security features. For example, one thing you can do is for the you see, the retina has to inputs like a the application processor may want to render some kind of some kind of user interface. So like a password prompt or a I don't notice a message. On the other hand, like the crypto processor wants to render like plaintext data. So in this case, the renderer is getting two different data streams. It could, for example, color coded. So to ask to make like spoofing of, for example, the application process of messages from a from Bii, like having a cipher text decrypted in the device a little harder. So you kind of know that if the Texas v. Texas blue, it's the application process, the interceptor directly talking to you. And it exists like Ratto something. It's the it's like a decrypted email you'r
e reading now if in this this scenario. So now I kind of like to decrypt and securely display GPG immense. Now, assuming I want to actually write an email, how would I do that when this case basically what you would have is you have this keyboard, DeCota and emulator on the top and bottom. So you have like the DeCota, which is reading all of my physical mechanical keyboard, and the emulator is then simulating another mechanical keyboard to the rest of his system, like implementation detail for two thirty would be that you can have like the function key, which is wired into the rest of the system as a physical data line instead of like multiplexed data lines. You could have that like, say, electrical override so that this keyboard emulator can only actually emulate the keyboard when you are pressing that key so as to like, still make it a little harder to exploit. That's an order, too, like, I don't know, and a command center or something. And the refillable would basically be like this. I would press like I would sort of start writing an email and then when my cursor is in the editing field, I would, for example, press a certain key combination which tells this interceptor device to and the application process within it to display me a like basically a very simple text. It just needs to be complex enough that I can enter like text in a language of my choice and to be like internally representing that Texas, some kind of like you'd have eight. Now I enter my email message into this application processor and then I would press on this case a certain key combination to, for example, I could like choose the recipient key ID, or I could possibly also communicate that information about extension that is highly implementation dependent. But in the end, the application processor would send the plaintext to the crypto processor, which would then input the encrypted ASCII Ahmed ciphertext via the keyboard emulator into my actual email client. Now, another interesting thing is
that here the krypto, like nobody but the cryptococcal processor, doesn't need any access whatsoever to the keyboard emulator because basically I don't I can't think of a reason why the application process of what would want to push keys on my keyboard. So in this case, I kind of have like the cryptochrome process of having exclusive access to the keyboard emulator and then it is entering this ciphertext as if I was be like typing GPG really fast. And my clients in this case wouldn't even necessarily have to know about that, because for it's for it. It's just a keyboard. Also nice thing about it is like there's no you don't need any operating system level drivers. You may not even need like application level support, for example, you could maybe you could have like parts of this like office bitmap, formatting, running in the cloud or something like on a different machine, which you trust more. So now we have like a physical device which can do some kind of encoding, like encrypting and decrypting of data, and which in order to do that, has to do key management. And I mean, putting a smart card next to it, I don't think it's a terrible idea. But still. That doesn't look too secure to me. Also, I have the advantage that's like compared to a full six mainboard, this system is pretty simple, like the you could probably do it with like a four layer PCB. So this is actually within the realm of possibility for a hobby is too like Soldo themselves. So I think one thing we should seriously consider that is making that taking that concept and making this device into an actual security module, as they are usually used to like stole SSL certificates and so on, because they are not actually that complex to build, I think. And that would present a much higher hurdle for an attacker to actually pull any plaintext or key data out of that system. The call suddenly and like not prosecute anybody is basically you have a intrusion detection feature on the circuit whereby the circuit d
etects when you open the case or drill holes in it or remove it from the device and you have like a backup battery that keeps that online no matter what happens. And the interesting thing about making an officer out of that would be that you could like, for example, have it wipe actively wipe a key when it detects that the case is being opened over the case of the prosecution itself or even just the laptop. So. Talking about how a security modules like how would we actually do that now, I have actually just assembled a couple of those myself. So generally most of the security modules that I actually use today basically consist of a some kind of CPU and some memory and some SRM, which is used for storage. And all of that is put in a box. And on the inside of that case box, there is like a so-called mesh printer. This is basically just to like PCB tracks printed on the inside of a case making their way all around it, contacting the main PCB at like a couple of points. And now the there's a part of the circuit inside the hardware security module that is continuously monitoring these traces, whether they are broken. And the idea is that in order to get to the keys, which are in the memory inside, you need to first open the case. And to do that, you need to break these tracks because they are all over the place and you can drill a hole in it without breaking them. Now, I think that can be done pretty easily and is pretty effective. For example, one of the more effective approaches I've seen in practice so far is like a basically a flex flexible plastic foil, which is printed with some kind of silver ink. It's basically exactly the same material you find inside really cheap keyboards, you know, on this rubber dumb things. And that stuff was just wrapped around the PCB on all corners. And then everything was puttered with a little flexible but really chemically resistant potting material like epoxy resin. And now as soon as you would try to remove that, it would totally ri
p apart these sensible traces on that on that plastic foil. I think that's a nice approach. I think there's a couple of other things I would kind of like to try. So like one thing is RF interference. So you have like a metal can instead of plastics and you have, like, just wire randomly stuffed into it. So you can't really predict where the wire is. And then you have it puttered and then you continuously measure the frequency response basically of the of different wires and traces within that case against each other, the coupling between them and measure when that significantly changes. Now, whether that works in practice, I don't know. It would probably be pretty expensive, but it might be worthwhile to at least explore what I could also imagine, like using a some kind of ultrasonic measurement. So you have like a positive bias. And on the main circuit board, you have a couple of small ultrasonic pixel transducers and you are sending like ultrasonic through the physical, like the the the potting material. And you are measuring if that response does change at all, I think that might actually be pretty effective, because in order to, like, open it or do anything to it, you would actually need to, like, touch it. And if you like, maybe you could use a laser against something like Advanceable. That would be that would be pretty cheap, though. This may come with like high current consumption. Another approach that I would like to try out is like tribal luminescence. So basically you put a couple of photo diodes through like really sensitive light detectors on the PSP itself, and then you encase everything with a clear potting material that is like mixed with like so-called like friction glow or smash glow crystals like that. Certain chemical substances, which in crystal form will emit a bright flash when you break the crystal or when you wrap two crystals against each other. And now if you would have that inside of your potting material, I think it would be really hard
to like in some way if the potting material is like chemically resistant in some way, like remove the potting material without exerting mechanical force on these crystals, which would cause them to flash. And you could detect that before to dilute and wipe all. Um, yeah. So these are like just ideas, what you could do in order to make this security model, like at least moderately resistant against an attacker. I mean, they are not bulletproof, like any helpful security module out that can be breached with sufficient resources. But the thing is, from all I've seen, this would probably already be like more than that, at least like most commercially available hardware security modules provide. I know some military stuff then like detonate the device. But yeah, we kind of don't want to do that. I think so. Now, I like praise, like this new idea for a device I have, which I want to put into a laptop. Now, one thing we need to consider that is like you are adding a and additional piece of like complex piece of circuitry inside a thing in order to, in the end, reduce attack surface. So like what attack surface does this device itself provides? So, like, this is not an exhaustive list, but is like things that I think are probably pretty critical, like one is. You need some kind of protocol decoding that thing, you need to, like find this head and the in-flight display signal, you need to like pass GPG payloads, you need to do some state handling on top of that. So that would definitely be a complex part. And there is some potential there to like construct Inverloch payloads, which may affect the state of the system and on some unintended way. Now, the countermeasure I would propose for that is a keeping it as simple as possible. The nice thing is sensors in hardware, we can kind of do that. We don't need to, like, configure Emilian registers in order to make some some some like video input, call on some system on chip. We can just exactly put into this piece of like fabric
what we need and nothing more. And also we have like some of that protocol handling running in like not really running, but implementing physical hardware circuits. And these are generally like you can't really, like, fuzz around with the state there, but you can probably not, or it will probably be harder than on a CPU to actually persistently modify the state in any useful way for an attacker. That's the social engineering rechter now. Yeah, the thing is, this would definitely be targeted as at like Fredi, capable people like not really like not really average users, so like people like you. So I guess in the end, social engineering will probably not be a terribly, terribly large, important attack scenario since my experience like. People like sufficiently knowledgeable about computers, somewhat decree's, and they're they're there in like they're being susceptible to social engineering attacks. Compromise is obviously an issue like what happens if somebody can, like, open the security module without admitting noticing? Yeah, well, the thing is, um, I think we can not eliminate that, but we can at least make it a little harder with this limited security model stuff. Um, I put in effigy back on up there because it was kind of like a like highly published topic, at least in, like, security research there. Now, the thing is, I don't think a pacto back to in this instance is super realistic because I think it would be really hard to make something into an FPGA that will actually provide any useful like compromise in that scenario. Um, logic, flaws. Well, obviously, you can have like logic flaws within the device. So I think we can do some stuff against that. So, um, the the thing is that since we we are implementing our own hardware there, we can do some more countermeasures than you can do purely in software. We can't, for example, have the code in a physically read only memory. So it cannot be modified no matter what. We can have, uh, like independence memories for d
ifferent things, like memory, for a memory, for heve memory, for codes and like have lots of arrows. If you try to do accessors across state boundaries, um, we can do some, we can do some like primitive separation of tasks into different use like crypto and application and rendering is I think like three major areas I can think of. We can do some hardware level access enforcements on places where we need to share resources. For example, in the FPGA implementation, we will probably have a common dirham external for all the pixel data. And we but we can like securely separate that by like hardware level access enforcement. So like the different components cannot write into their respective address spaces. Um, we can generally keep it simple. So if it's like too complex, it will, I think, really hard to keep it secure. Um, but if we keep this super, super simple, at least compared to a full blown platform, I think we can actually keep the attack surface within the manageable area and actually all the thing to a meaningful extent. Um. Like, one thing I would like to note here is that, for example, for the CPU's, one thing that would really lend itself to it would be the risk we project, which are who are currently actively working on a basically entirely open source CPU that is pretty well specified, pretty well tested, like they are even some efforts to actually prove it, that it works like logic, logically proof the functioning of it. And that's also some work on, for example, tact, memory and other like hardware level security mechanisms. They have like another thing I would like to point out is that since all of these parts of this system are operating at a very low level, we can just reset everything really frequently. It's not bulletproof, but it can at least make attackers life lives harder, because if we, like, reset the entire state of the system like everything but the actual keys, every frame or something or every time a new payload is received, it will be mu
ch harder for an attacker to actually compromise the state and bring it to any to any new state that is useful to the attacker. It will not prevent anything, but it will at least like make the practical exploitation harder now. Considering this attack surface, like what would be practical scenarios with this device and a laptop and with the same laptop without that device. So I just wrote down a couple of those little made like little colorful tick marks on how it would perform. Obviously, this is not absolute. It like depends on the implementation and on the how you are particularly using it. But I think as a general guidance, this should perform quite well. So like in the last device case, for example, if you don't have this kind of interceptor inside the device, you can already get pretty secure solutions. If you are using secure but correctly, if you are encrypting a hard disk, if you are soaring your keys in some kind of secure memory and so on. But it depends on the implementation. And like with this intercept device, I think it will be a little easier to actually make sure that if you lose the device, you like the idea that neither the keys themselves nor any plaintext can leak the device. Now, second scenario is like unlock device stolen. So somebody comes and takes your laptop away while you're working at it and you don't have time to lock the screen. Now, the thing is, fundamentally, you will have the same problem if you kind of unlock this intercept device over a period of time. But the thing is that since you only need this interceptor device in order to decrypt and encrypt MS and you don't do that all the time, you can have it blocked most of the time that your screen is unlocked. Also, some since this intercepted device like Hotfoot, we are building ourselves, we can include additional security features that are not offered in Off-The-Shelf laptops, for example, we could have like some capacitive sensor in the Palmeiras that is detecting when, like, yo
ur hands are removed from it. And that will just wipe the keys in that case. And then you need to reenter your password. That would be too annoying for something that would lock the screen. But like for Weiping, like a clearing, a hearing, for example, that might be a adequate like a tradeoff. Now, target to attack what I described as a targeted attack is basically somebody with a lot of money really doesn't like you. So, for example, somebody specifically wants your email now, Vodoun Interceptive, you really have a problem, because even if you are using locutions and you encrypting everything with GPG, in the end you have a off the shelf Linux operating system with X and hypervisor running on a platform with lots of proprietary firmware and many places that are handling plaintext data. And also this system, the entire stack is so complex that I think it's practically guaranteed for every part of it that there will be flaws. And we see that all the time. For example, Apple's iPhone has a really good security architecture, but it's still pretty complex and people are getting around us. Also fix the X and hypervisor, which is on Hueso s, which is the primary isolation feature there. That thing is also highly regarded. Still, there have been flaws found in it because it is a huge, complex thing. And I think we can lower that attack surface by basically concentrating it on this interceptive device, which really only prevents very simple interfaces to the outside world, which I think we might be using, which I think might be easier to actually audit. Now, an obvious failsafe scenario for like both things like a laptop with or without this device would be like you are blocked. So like somebody places a camera behind you and your flat, your apartment or something, because like since you need plaintext data coming out of your screen at your eyes, since we don't have krypto glasses. Like anybody in the same room will be able to kind of foom that, like even if you're using li
ke one of these privacy filter things, like at the right angle, people will be able to read it. So in that scenario, obviously, any mechanism that still uses a display will fail. Um. You may like you some kind of Snowden cloak or something, but, yeah, I think that would be really hard physical access. So like somebody has temporary physical access to your device, like during shipping or at the border checkpoint. In that case, I think it depends on any in any instance, because without intercept, well, maybe they can, like, install a rootkit exchange. It would flash or something with the intercept. Well, maybe they can place an interceptor in front of the interceptor or something, you know, like there's really nothing you can do that if you you don't even know whether you getting the same laptop back or whether it's like a I don't know, some simple device, which is just like which includes like monitoring for CPU and, uh, for keyboard and display. So I think in that in that case, like, we can make it a little bit harder by having, like, these sort of security modules, features to like detect when the case is open so we can provide some incentive against, like opening the case and messing around in the system there. But it won't be bulletproof, um, like total communications surveillance as it is happening in practice. I guess that's that's like any system is pretty secure. And the way that we are leaking metadata, we are leaking metadata is really hard to avoid that. The difference is with the intercept. You're also just leaking metadata instead of plain text to your operating system. But that might not be like for communications. So that's irrelevant. Now, what needs to be considered, of course, is that by placing an additional device in your laptop, you are actually from a whole system point of view. You are increasing attack surface. And if that device like this interceptor would be compromised, that would be totally game over because it has access to your two most
privileged things and the laptop like the display output and the keyboard input. Um, so basically any secrets you communicate to your computer are there on these busses. So I think that we need to be really careful implementing this in order to not make this an actual security, a security threat instead of a security feature. Major tasks I have, like I think we have we need to solve in order to actually make this practical are basically disassembling and reassembling this, I might add, this report and stuff, because as it turns out, it's not easy if you have some expertize. And that's I'm really interested in feedback and suggestions there. I think rendering Unicode will be hard. I mean, we want to we want people to actually be able to communicate in any number of languages with this device and actually supporting Unicode font rendering on a embedded thing. And that in a secure way. I don't think that be trivial. Then we need to define this packet's payload format in a secure way. So like it cannot doesn't provide too much complexity. We need to get the keyboard passed through semantics. Right. So don't accidentally input sensitive data into your host machine without you really noticing it. We need to split like this and do this entire process. Separation like cryptochrome process was application for processing in some sense of a way that we actually gain something by it and we don't have like a huge amount of code running in the process of, for example. And I think the if he if we want to implement this with the smart card as a Keystart like long term storage, it will probably also be hard to get that right, because I don't think as a private citizen, you can just go out there, buy a smart card software development kit and write your own as a force for forty nine to six like geeky handling on the smart card. So we need we may need to figure something out that if we want to do that now, I don't know. I hope I could actually like I could make you interested in that i
dea if you have like any feedback, any suggestions, any ideas or like some expertize, even in the relevant fields. I'm really interested in feedback and help with this. I'm reachable like that email address. The key is below. And this talk like the slides will be on the GitHub repository up there. So you can also just give feedback as by raising an issue that if you have something, um, thank you for listening. Everybody that who I haven't bought to heart you, I think we can do a question and answer session now. Yeah, thank you very much. That was enlightening. That takes us to the Q&A. There are two microphones set up here. Please form an orderly queue. I'll try to make sure that I realize who's first. And we would just wait for the people filing out for a second, I think, because we we got enough time, don't we? I think so. Great. Ten minutes. Q&A answer, I think, will pick me. OK, we started that, Mike, and then ping pong to the room. Yeah, so as far as I understand, the idea of the interceptor on the keyboard side is that plaintext goes in, ciphertext comes out. Yes. All right. So I would like to edit all of my emails in Emacs or vem with all of the fancy packages on line. Obviously, we will need to compromise like some amount of usability there, except if you want like a full imex instance running in that intercept. I mean, technically it's possible. Yeah, you can like in these refugees who can actually make the development system and using you can actually run a full Linux in there. But I don't think you would want that because it would pose like some attack, as I think. Yeah, but generally the benefits of having your applications in software rather than hardware is that you can update them. Also, new crypto protocols, better encodings than UTF eight. All of that is lost in your design. Yes. Or could you maybe make the monitors a little louder? I can barely understand them. So I repeat, shall I repeat the question or you got to, like, update ability of the phon
e? Yeah, yeah. I mean, the thing is, you can like if it is implemented in the FPGA, not in an ASIC, you can actually easily update it. I think it is very sensible to make it as hard as possible to actually do that in practice. Like you need to open the hardware security module and like flip some switch or place a jumper or something as to make it impossible to do that via a software only attack, for example. And like, if you do that. Well, yeah, you could update us. OK, yeah. OK, how do you actually know that what you're seeing is coming from the interceptor and how do we know that when you're typing it's actually being intercepted and not going to the hardware? That question. So I don't actually know that what I'm seeing. Oh, OK. Well, it depends. Like, I cannot absolutely know it because somebody could have placed like an interceptor between me and the interceptor. Now, just like I think the other way to talk about it is like what I want to have is I don't want a application on my operating system being able to spoof intercept output. I think one way to make that is to have the urge to have a like the easiest way to implement that in practice would be to have just the intercept always and full screen and use one of the physical LEDs on the keyboard of a pat in order to like, signify where the input and output is going is coming from and going in to the interceptor or from the underlying device. So you have like the you could repurpose them, you'd make muite led of immutability for that. Other possibilities would be like for the output case to like draw a border around the screen. And if it's red means like Linux talking, if it's green, it means like interceptive talking for the input. Basically the same thing. You could have some like visual clue. I think the input case will be pretty like in order to get that right would be pretty hard because we don't want you to accidentally input a password. And if you input a password often you don't necessarily care that muc
h about the screen. Why? Look why you were typing it. So I think a visual clue might even be not enough in that case. Well, I guess we finally found a good use for the think bondage button. Well, except that one can be controlled from the CPU. Yeah, somebody mapped it to Newt Newt on whether they did the signal. The Internet is talking to us. Yeah. So the first question is, would the interceptor work in a way cavium does? So instead of adding a chip to the main board, you put a box next to the computer to which you plug the keyboard and the display and the box just presents the encrypted input to the computer. Definitely like in a desktop use case. That would definitely be how I would implement it in the laptop use case. Obviously, it's tempting to actually include it in inside the actual case for some extra 30. We could just replace the hard disk with a smaller SSD and use the free space there because it's already quite close to display and keyboard connections. OK, I really like I really like the creative idea, but I was wondering how you feel about I mean, you touched upon the open the risk C.P.U implementation that we not open risk, so risk the risk fee. OK, I'm not sure. But the university in England, where they are doing research on an open architecture and if you go into towards that direction, wouldn't how do you feel about having a system on its own that you can trust instead of having an implementation in a regular machine? I think that would be really interesting. Like the that that is one of the more interesting points of actually doing this. I mean, the thing is, we can still you can still use, like all the amenities of your operating system with like Compiz wobbly windows and like windows hourglass depending on the operating system. But you also get like this trust it, the trust aspect from the C.P.U implemented in the FPGA. So like for a start, I would definitely keep the firmware running inside. It's as simple as possible in order to avoid like makin
g the crash and like avoid like adding a khattak surface there. But yeah, of course, like long term, you might want to add more functionality into it with sufficient isolation. Of course. Thank you. OK, the Internet is at it again. Just a short question. What about USB keyboards? Yeah, well, it depends. Like if you have some means of plugging that into the intercept on an issue like USB is still simple enough that you could implement it with some effort on an FPGA like both hosts and device parts in the laptop use case. I don't think it will be that easy because you would need to intercept like all the USB ports. I understand that the whole point of a device like this is to bring about something like the Krypto goggles you mentioned at the beginning, but in a more limited fashion. However, it does seem like there's opportunity for the solution that you've proposed to have integration points for operating systems like Genard and Cupolas and so on and so forth. Is do you think that there's another angle, this a different thing that you can isolate, or is this the only way in which it can be done? And if it's this is the only way which can be done to the things that you propose that should be done? Are there any integration points for operating systems like that? I mean, I don't think this is the only way you could do something like this. For example, you could also like for a much like from a implementation point of view, much simpler architecture. You could just have a device packed into your USB port, which has a display and a keyboard like separate to your regular displaying keyboard. Like the only difference would be it would be a little less convenient to use. So I think there will be there are other many other ways. It I think the intercepting the actual display data thing is kind of interesting because it's pretty portable across platforms. As for integration points for like the operating system, especially something like Huff's, I think there's a lot of potent
ial. I mean, I would I didn't think about that much yet because think about like A.I.M. made being integrated with the system that you're talking about. You made for a pretty resistant system that cannot be spoofed. Yeah. I mean, you could also, for example, you could even like in case of cubes, you could integrate that. Some of that. I think you could actually integrate into the display manager in order to have like both Qs and the interceptor cooperating. So like Cubes knows what the interceptor is doing and can actually, for example, you could maybe handle the inputting your password into the wrong device. The thing there, OK, whatever. That was my screensaver. OK, there's another one from the Internet. Yeah, what about ciphertext that are longer than would then what would fit? Almost nice Christian like the same thing goes, by the way, for plaintext that is longer than what fits on the screen. Like, I didn't touch upon that too much. But basically what it would do is you would spread across different frames since the like the actual pixel bandwidth, the bandwidth for pixel data on a like even on a low resolution display, like the display of that laptop is like already in the gigabit per second range. So no matter how long your emails are or what amount of ciphertext you are outputting there, you will be able to stuff it into consecutive frames. You will have some processing limitations on the FPGA because it's like trolly clock pretty slowly and you will have some like memory limitations also. But like, I think for a general system at the cost of a slightly higher complexity of the protocol handling in the intercept, this can be solved. And for the outputs case, like you just scroll, you just need to wire like the up and down arrows, all a screen up and screen down keys to like the renderer or something. Thank you. OK, so your main argument was that your system is less complex and therefore less attackable, but then I wonder why you make the effort of intercepti
ng your traffic? Like from my experience, I guess about 90 percent of the complexity of that system will be on intercepting the display data. So if you want to have something plain and simple and with a low attack surface, why you don't use is just a standard four times 20 LCD display and just intercepted the keyboard line. And this would be doable and like one or two days and you could even let it run on SDM thirty two point FPGA. But that would be boring. No, seriously, I think the V.V. like doing the life interception of display data has a serious usability advantage in that you can like in my laptop use case I have this laptop looks exactly the same as before, except for providing me this high assurance for like certain operations, like with any kind of external device. I would need to carry that around, need to have it, and then like use two different keyboards and two different displays of different things. And like I think for serious email reading, at some point you would want, like a serious display on that thing and on that at that point, it gets just as complicated. Also the like considering the development time. Yes, intercepting leads and embeddedness report is a lot of work, but that's not because it's super complex, but because it needs to be tuned. Pretty. Pretty, exactly. Because you need to take care of a lot of details there, like face alignment and stuff like that. OK, thanks, next question. How exactly do you think there's going to be something on the CPU sending your text away or whatever, doing with it? And if there would be something like that, why do you think it would pass something like Wireshark listening on the network? I mean, if you have, like a some kind of spyware running on your operating system, intercepting, for example, all encrypted emails before encryption, you might not actually be able to discern that on why even using Wireshark, if the if that spyware is any good, like if it's any good, it would probably be using like some s
teganography techniques in order to hide its own traffic inside your usual traffic so you can't easily detect it. OK, thank you. OK, OK, so I understood your proposal for writing email. And with that, so if you're hitting on a key, it's doing something and it encrypting it and putting it into a buffer for the operating system to pick it up, to place it in the application buffer. Right. So if if that is correct, what kind of encryption do you plan to do on the actual keep pressing? So if it's your own publicly, how do you. How do you actually send an encrypted email to somebody else with their public key that highly depends on the implementation? Like my first approach would be to try to extend an email. So the if you open an email, you're typing like the recipient and plaintext because that is metadata anyway. And then in email will use like the same payload format in order to provide the public key of the recipient. Ideally, with the signature of your own private key to the interceptor, so that thing can actually then display the V.V., the key, like the kid of the recipient asked, validated by your own signature with the key that it's private with the with the private key that is only contained within the interceptor. It's a little awkward, but I suppose it can be done. Another way would be to do the entire key management in the interceptor. So you kind of press a key combination and a menu pops up and you then like choose the recipient's email address by typing in their. OK, we got one more question. Not really a question, just like I think you have found a good use case for the dodgeball, but it's good for Newt. Newt to one more serious question. Right. I missed the beginning of the talk. So is this already, like, ready? Do you have a prototype ready? I wish I guess at this point I have two small Raspberry Pi zeros in my laptop and I'm able to close it perfectly. And so this is what I'm trying to do exactly what you're doing. But I'm planning on having one contro
l or control of the keyboard and then want to control the network so I can separate those out. So have you thought about, you know, maybe something like that? Yeah. I mean, the thing is, I would like to avoid, like, arms talks like Sussman or Chips, because all of them, like Broadcom, Qualcomm, Texas Instruments, I've seen some of the insides of them. And it's not pretty like it's super complex. And I don't think they're any easier to secure than the Linux. You are running like Qualcomm, for example, making arms talks, just had like several serious breaches of their hypervisor and trust and security in the last months. So I think we can basically rule out like any modern arms. OK, well, thanks, everybody.
