 I'm going to talk to you about an idea ahead 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 you use them for, but I use the most important thing I think I'm doing with my computers 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, GPGE or OTR or Signal, like, are executing in a, like, basically this. So this is a block diagram of a modern computer, in this case the Lenovo X230 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 GPGE 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, is going all over the place. So we have, like, a super complex system. We have, like, also in this case the bad-highlighted things are, like, subsystems that contain some form of proprietary firmware which we cannot audit. And all of this makes it, 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. Actually, 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 it gets sent and encrypted and decrypted, and on the other end it's displayed on the screen as words and my friend reads it. Now the thing is that as you can see from my block diagram, I've highlighted, like, the parts that I actually need for that communication in green, like keyboard and display. If we say that, okay, at the display and at the keyboard I basically need to use plain text because crypto glasses are not yet a thing and also I cannot really type in RSA or something, so in the end I kind of need to have plain text there. But on the other hand I don't really want to trust all of that other stuff, especially like these things running untrusted firmware, like the things with red borders. The problem in that case is, like, since a couple of years now Intel has gifted us something, namely CPUs and basically the platform controller hub which is containing the integrated graphics which are both running proprietary, pretty reverse engineering-resistant firmware. So I have these, 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 plain text. But on the other hand, like, I have no choice because there, you see all the errors are pointing to it. There's 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 plain text 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 terribly high chance that we will be, like, reverse engineering, Intel management engine and embedded controller firmware 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 bus or display buses, in case of its laptop that's primarily a LVDS bus, which is a digital display bus, on more modern devices you would use embedded display port, which is basically very similar to LVDS, 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 embedded, like, this laptop and I think most other Lenovo 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 LEDs for, like, mute and power. So from this point of view, we need something in between of these components that will be receiving hopefully only untrusted ciphertext from Cloud Platform Controller Hub, which contains the integrated graphics and the embedded controller, which contains the basically keyboard matrix scanning, and forward, 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, like, embedded display port and HDCP and so on. So the thing is, now, if we look at that block diagram, so you have, like, CPU and embedded controller, Platform Controller Hub, the intercept, the display keyboard, and these two pretty simple buses. That has a nice side effect of implementing a system that way, and that is that these two simple buses are used pretty widely. For example, this is a block diagram of what, in this case, Texas Instruments would like your smartphone to look like. It's pretty much the same for all vendors. They basically just exchange, like, who makes the parts? They all do basically the same thing. You have, like, the CPU in the middle of this application processor, which, in fact, is a huge system on a chip, like, more than once, even include, like, packet-switched memory buses and stuff like that, so really advanced stuff. But in the end, that thing is only talking to your display via something either similar to LVDS, some are even using embedded display port, so, like, high-speed serial protocol, but still pretty dumb. And, I mean, you don't have a keyboard in most smartphones, but you have, like, touch screen, and these touch screens are generally also controlled over, like, this pretty simple serial protocol, like, I-square-C. So, we can definitely adapt the solution from before to also work in a case like this. You will obviously have, like, power management issues and form factor issues, but purely technically from the electronic and computer science side of things, this should work. So, if we look at this block diagram of this general idea on how we could organize our computers, we have this interceptor device. Okay, so it needs to kind of do something with LVDS, like, receive it, process it, send it back out, and do, like, something with the keyboard switch matrix scanning, like, how does this, like, how would you actually control that from an application point of view, from software running on the host machine? Basically, this is the general idea I had for that. This is a diagram of what a frame sent from a basically, basically any monitor standard today looks like. You have, like, this vertical sync and horizontal sync signals which basically are framing information, stemming from back when VGA was a thing. And then you have, like, the actual content area where most of the time you have some kind of desktop environment running, and then you have, like, a application window inside that desktop which may contain something worth protecting. Mm-hmm. As an example, think, for example, of Thunderbird where you want, where I want to send, like, 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. In case of I'm receiving an encrypted email, that window is displaying, like, basically, if I would not have, like, a NIC mail or something installed with basically display, like, ASCII, Armored, GPG binary. Now, what we need to do in this, to make this work, in this scenario is we have some kind of Thunderbird add-on which recognizes that I'm displaying, like, GPG Armored, GPG ciphertext, and which will take this GPG armor, like, convert it back to binary form, and then formatted it as a simple bitmap. That contains a special header at the front that tells the interceptor device something like the width and height of the bitmap and contains a authentication code, so I cannot just anybody go and form a bitmap which would work with my interceptor 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 my GPG key, the interceptor, since it has access to the keyboard and display may ask me to input a passphrase or to, I don't know, insert a smart card or something depending on the implementation. And the decrypted plaintext is then rendered into a pixel buffer which is inserted in the live 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 add-on so the entire window where I'm reading my email would be this payload area and contain the GPG 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 buses like LVDS and do in-flight transformation on it. So that's a pretty hard task. And also we want it to be somewhat not too complex so we can actually secure the thing itself so we don't just replace one huge attack surface with another huge attack surface. Now, to me, the most obvious way to do this would be to use an FPGA for most of the 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 in display bus. And yeah, this is basically how I would imagine a such an FPGA-based interceptor to work. By the way, sorry for the non-planar graph thing. So without looking too much into it, we can already see that we have an advantage against this X86 platform like the Lenovo X230 here in that we do still have a lot of components but they're not that centralized. There is some factor of compartmentalization there. So I have, for example, 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 go in this diagram, it will go up, go in on the bottom right side which is basically from the untrusted domain from the platform controller hub on Intel platforms, it will go through a LVDS DC serializer which basically converts it into a smaller frequency, lower frequency signal for FPGA internal use. That will go into a pattern detector. Now, if that pattern detector does not detect like this special marker header I put in front of my GPG payload, it will not do anything, it will just pass on the signal. The signal will then go through a frame buffer for like clock 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 a 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 shift registers, pattern matching and a couple of buffers. So in this way I can organize this system so that like sensitive data is really only touching parts it absolutely needs to touch like from an electrical point of view there's like on the FPGA separate buses 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 either in the FPGA itself or in a external secure access module so basically a smart card and the CPU and graphics processor which formatted that data for me do not know that key so that can't decrypt it. They're just running basically a bitmap graphic and now the pattern detector in this device will when it's receiving this data recognize that header which was previously formatted and then it will go on and write the payload in this case like a probably some lightweight protocol and then the actual GPG data into a payload buffer and upon completion it will notify something I call the application processor because basically I think you will probably need something like that and this application processor will then do processes on that. Like in fact what it will do in the GPG use case is it will probably do some protocol decoding then extract the actual cryptographic payload send that on to a crypto code processor. I think it makes sense to distinguish these two things here because A, the application processor 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 and decryption and handling of plain text. And this crypto code processor would then decrypt this payload possibly with the help of a smart card secure access module and will then forward the plain text via a separate data path to the renderer. So physically the application processor in this scenario would never be in possession of the plain text so even if you compromise it through some way or some means you would not be able to access plain text data there. And the renderer would be a piece of basically probably another processor realistically probably running something like free type that is converting like UTF-8 input 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 like outputting a bitmap into a render buffer and this render buffer is then dynamically switched into the in-flight LVDS or embedded display port signal by this buffer switch thing. So the buffer switch basically just needs like the position where to flip between upstream display content and the render buffer and it will count the position in X and Y coordinates and then switch over and switch back. Now this nice thing about like this entire compartmentalization thing is that it enables also some kind of some need security features. For example, one thing you can do is for the, you see the render has two 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 know, some message and on the other hand, like the crypto co-processor wants to render like plain text data. So in this case, the renderer is getting two different data streams. It could, for example, color-coded. So as to make like spoofing of, for example, application processor messages from a, from by like having a ciphertext decrypted in the device a little harder. So you kind of know that if the text is blue, it's the application process of the interceptor directly talking to you and if the text is like red or something, it's like a decrypted email you're reading. Now, if in this scenario, so now I can like decrypt and securely display GPG emails. Now, assuming I want to actually write an email, how would I do that? Well, in this case, basically what you would have is, you have this keyboard decoder and emulator on the top and bottom. So you have like the decoder, which is reading out my physical mechanical keyboard and the emulator is then simulating another mechanical keyboard to the rest of the system. Like implementation detail for X230 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 multiplex data lines. You could have that like as an SA 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 in order to like, I don't know, enter commands into your root shell or something. And the workflow would basically be like this. I would press like, I would start a phone number, 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 processor within it to display me a like basically a very simple text editor. 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 text as some kind of like UTF-8. Now I enter my email message into this application processor and then I would press in this case a certain key combination to, for example, either I could like choose the recipient key ID or I could possibly also communicate that from a Thunderbird extension that is highly implementation dependent but in the end the application processor would send the plain text to the crypto processor which would then input the encrypted ASCII armored GPG cipher text via the keyboard emulator into my actual email client. Now another interesting thing is that here the crypto, like nobody but the crypto core processor does need any access whatsoever to the keyboard emulator because basically I don't, I can't think of a reason why the application processor would want to push keys on my keyboard. So in this case I can have like the crypto core processor having exclusive access to the keyboard emulator and then it is entering this cipher text as if I would be like typing GPG really fast. And my email clients in this case wouldn't even necessarily have to know about that because 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 it. For example you could maybe you could have like parts of this like of this 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 like compared to a full x86 main board 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 to like solder themselves. So I think one thing we should seriously consider there is making that, taking that concept and making this device into an actual hardware security module as they are usually used to like store 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 plain text or key data out of that system because suddenly in like the hardware security model is basically you have a intrusion detection feature on the circuit whereby the circuit detects 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 in hardware security model 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 either the case of the hardware security model itself or even just the laptop. So talking about hardware security modules like how would we actually do that? Now I have actually disassembled a couple of those myself so generally most hardware security modules that I actually use today basically consist of a some kind of CPU and some memory and some SRAM which is used for key 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 printed. This is basically just two like PCB tracks printed on the inside of the case making their way all around it contacting the main PCB at like a couple of points. And now there's a part of the circuit inside the hardware security model 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're all over the place and you can't drill a hole in it without breaking them. Now I think that can be done pretty easily and it's pretty effective. For example, one of the more effective approaches I've seen in practice so far is like a basically a 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. These rubber dome things. And that stuff was just wrapped around the PCB on all corners and then everything was potted with a kind of 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 rip apart these sensible traces 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 plastic case 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 potted and then you continuously measure the frequency response basically of different wires and traces within that case against each other. The coupling between them and measure when that significantly changes. Now with that works in practice I don't know it would probably be pretty expensive but it might be worthwhile to at least explore it. I could also imagine like using a some kind of ultrasonic measurement. So you have like a potted device and on the main circuit board you have a couple of small ultrasonic piezo transducers and you're sending like ultrasonic through the physical like 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 it or something I don't know. Like advantage of that would be that it 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 photodiodes so like really sensitive light detectors on the PCB 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 there are 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 the 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 with your photodiode and wipe all keys. Yeah, so these are like just ideas what you could do in order to make this hardware security model like at least moderately resistant against an attacker. I mean they are not bulletproof like any hardware security model out there can be breached with sufficient resources. But the thing is from all I've seen this would probably already be like more than at least like most commercially available hardware security modules provide. I know some military stuff then like detonates the device but yeah, we kind of don't want to do that I think. So now I've like praised like this new idea for a device I have which I want to put into a laptop. Now one thing we need to consider there is like you are adding an 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 provide? So like this is not an exhaustive list but it's like things that I think are probably pretty critical. Like one is you need some kind of protocol decoding in that thing. You need to like find this header and the inflight display signal. You need to like pass GPG payloads. You need to probably 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 invalid payloads which may affect the state of the system in some unintended way. Now the counter measure I would propose for that is A, keeping it as simple as possible. The nice thing is since it's in hardware we can kind of do that. We don't need to like configure a million registers in order to make some video input call on some system on chip working. We can just exactly put into this piece of like FPGA fabric what we need and nothing more. And also we have like some of that protocol handling running in like not really running but implemented in physical hardware circuits. And these are generally like you can't really like fuzz around with the state there but you can't really not or it will probably be harder than on a CPU to actually persistently modify the state in any useful way for an attacker. There's the such an engineering vector. Now, yeah, the thing is this would definitely be targeted as at like pretty 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 in my experience like people like sufficiently knowledgeable about computers somewhat decrease in their being susceptible to social engineering attacks. Physical compromise is obviously an issue. Like what happens if somebody can like open the hardware security model without it noticing? Yeah, well, the thing is I think we can not terribly like eliminate that but we can at least make it a little harder with this limited hardware security model stuff. I put an FPGA 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 FPGA back door and this instance is super realistic because I think it will be really hard to bake something into an FPGA that will actually provide any useful like compromise in that scenario. Logic flaws well obviously you can have like logic flaws within the device so I think we can do some stuff against that so the thing is that since we have we are implementing our own hardware there we can like do some more countermeasures than you can do purely in software. We can for example have the code in a physically read only memory so it cannot be modified no matter what. We can have like independent memories for different things like memory for stack and memory for heap and memory for code and like have lots of arrows if you try to do accesses across their boundaries. We can do some primitive separation of tasks into different CPUs like based crypto and application and rendering is I think like three major areas I can think of. We can do some hardware level access enforcement on places where we need to share resources for example in the FPGA implementation we will probably have a common DRAM 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. We can't generally keep it simple so if it's like too complex it will be I think really hard to keep it secure but if we keep this super super simple at least compared to a full blown x86 platform I think we can actually keep the attack surface within the manageable area and actually order the thing to a meaningful extent. Like one thing I would like to note here is that for example for the CPUs one thing that would really lend itself to it would be the risk v project which are who are currently like actively working on a basically open entirely open source CPU that is pretty well specified, pretty well tested like there are even some faults to actually prove it that it works like logically proof the functioning of it and there's also some work on for example tech memory and other like hardware level security mechanisms there. Like another thing I would like to point out is that since all of these parts of the 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's 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 much harder for an attacker to actually compromise the state and bring it to any new state that is useful to the attacker. It will not like 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 in a laptop and with the same laptop without that device. So I just wrote down a couple of those and I made like little colorful check 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 lost 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 boot correctly if you are encrypting your hard disk if you are storing your GPG keys in some kind of secure memory and so on but it depends on the implementation and like with this interceptor device I think it will be a little easier to actually make sure that if you lose the device you like neither of the keys themselves nor any plain text can leak the device. Now second scenario is like unlocked device stone. So somebody comes and takes your laptop away while you are 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 interceptor device over a period of time. But the thing is that since you only need this interceptor device in order to decrypt and encrypt emails and you don't do that all the time you can have it locked most of the time that your screen is unlocked. Also since this interceptor device like hardware we are building ourselves we can include additional security features that are not offered off the shelf laptops. For example we could have like some capacitive sensor in the palm rest that is detecting when like your 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 wiping like clearing a GPG key ring for example that might be a adequate like trade off. Now targeted attack or what I described as targeted attack is basically somebody with a lot of money really doesn't like you. So for example somebody specifically wants your email. Now without an interceptor you really have a problem because even if you're using like cubes or S and you're encrypting everything with the GPG in the end you have a off the shelf Linux operating system with Xen hypervisor running on a X86 platform with lots of proprietary firmware and many places there are handling plain text 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 found 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 it. Also for example the Xen hypervisor which is underlying Q-SOS 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 interceptor device which really only presents very simple interfaces to the outside world which I think we might be which I think might be easier to actually audit. Now not this failure scenario for like both things like a laptop with or without this device would be like you're bugged so like somebody places a camera behind you in your apartment or something because like since you need plain text data coming out of your screen at your eyes since we don't have crypto glasses like anybody in the same room will be able to kind of film that like even if you're using like one of these privacy filter things 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. You may like use some kind of Snowden cloak or something but yeah I think that would be really hard. Physical access so like somebody has temporarily physical access to your device like during shipping or at a border checkpoint in that case I think it depends in any instance because without interceptor well maybe they can like install a root kids exchange your boot flash or something with the interceptor well maybe they can place an interceptor in front of the interceptor or something you know like there's really nothing you can do there if you don't even know whether you're getting the same laptop back or whether it's like a I don't know some SIM device which is just like which includes like monitoring for CPU and 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 hardware security modules features to like detect when the case is open so we can like proofs provide some incentive against like opening the case and messing around in the system there but it won't be bulletproof. Like total communications surveillance as it is happening in practice. I guess that's like that any system is basically secure in the way that we are leaking metadata. We are leaking metadata it's really hard to avoid that. The difference is with the interceptor you're also just leaking metadata instead of plain text to your operating system but that might not be like for communication surveillance 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 cause it has access to your two most privileged things in the laptop like the display output and the keyboard input. So basically any secrets you communicate to your computer are there on these buses. So I think that we need to be really careful implementing this in order to make this an actual 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 embedded display port and LVDS stuff because as it turns out it's not easy. If you have some expertise in that I'm really interested in feedback and suggestions there. I think rendering unicode will be hard. I mean 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 would be trivial. Then we need to define this packet payload format in a secure way so like it cannot it doesn't provide too much complexity. We need to get the keyboard path through semantics right so then accidentally input sensitive data into your host machine without you really noticing it. We need to split like this and do this entire privilege separation like CryptoCroprocessor was application processor in some sensible way that we actually gain something by it and we don't have like a huge amount of code running in the CryptoCroprocessor for example. And I think if we want to implement this with a smart card as a key store like long term key 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 see what software development kit and write your own RSA 4096 like GPG key handling on the smart card. So we may need to figure something out there if we want to do that. Now, I don't know. I hope I could actually like I could make you interested in that idea if you have like any feedback, any suggestions, any ideas or like some expertise even in the relevant fields I'm really interested in feedback and help with this. I'm readable out like that email address the GPG 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 there if you have something. Thank you for listening. Everybody who I haven't bought too hard 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 will just wait for the people filing out for a second, I think, because we got enough time, don't we? I think so. Great. Yeah, 10 minutes. Cue and answer. I think they'll pick me. Okay, we start at that mic 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 plain text goes in, ciphertext comes out. All right, so I would like to edit all of my emails in Emacs or Wim with all of the fancy packages I found online. Obviously, we will need to compromise like some amount of usability there, except if you want like a full Emacs instance running in that intercept. I mean, technically it's possible. Yeah, yeah. You can like in these FPGAs, you can actually like the development system I'm using, you can actually run a full Linux in there, but I don't think you would want that because it would purse like some attack surface, I think. Yeah. More generally, the benefits of having your applications and software rather than hardware is that you can update them. Also, new crypto protocols, better encodings than new TF8. All of that is lost in your design, yes? Or most of it. Could you maybe make the monitors a little louder? I can't barely understand them. So... Shall I repeat? Shall I repeat the question? Or you got it? So like, updateability of the firmware. Yeah, yeah. You lose the benefits. I mean, the thing is you can, like, if it is implemented in an FPGA and 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 it. Okay, yeah. Okay, how do you actually know that what you're seeing is coming from the interceptor and how do you know that when you're typing, it's actually being intercepted and not going to the Intel hardware? Nice question. So, I don't actually know that what I'm seeing. Oh, okay, well, it depends. Like, I cannot absolutely know it because somebody could have placed like an interceptor between me and the interceptor. Now, like, I think the other way to talk about it is like, what I want to have is like, I don't want a application on my operating system being able to spoof interceptor output. I think one way to make that is to have the, to have a, like, the easiest way to implement that practice would be to have just the interceptor always in full screen and use one of the physical LEDs on the keyboard of a ThinkPad in order to like, signify whether input and output is coming from and going into the interceptor or from the underlying device. So you have like the, you could repurpose the MICMUTE LED or the MUTE LED for that. Other possibilities would be like, for the output case to like, draw a border around the screen and if it's red, it means like, Linux talking, if it's green, it means like interceptor talking. For the input, basically the same thing, you could have some like, visual clue. I think the input case will be pretty hard, like in order to get that right, will 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 much about the screen while you're looking, while you're 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 ThinkVantage button. Well, except that one can be controlled from the CPU. Yeah, somebody mapped it to NUDE-NUDE on, okay, anyway, the signal angel, the internet is talking to us. Yeah, so the first question is, would the interceptor work in a way KVM does? So instead of adding a chip to the mainboard, you put a box next to the computer into 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 inside the actual case. For example, in X230, we could just replace the hard disk with a smaller SSD and use the free space there because it's already quite close to the display and keyboard connections. Okay. Hi, I really like the creative idea, but I was wondering how you feel about, I mean, you touched upon the open, the risk CPU implementation that they are doing. Risk V, not open risk. Sorry? Risk V. Risk V, yeah. Okay, I'm not sure about the university in England where they are doing research on an open architecture. Yeah. If you go into towards that direction, 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 that is one of the more interesting points of actually doing this. I mean, the thing is we can still, you can still use all the amenities of your operating system with like compass, wobbly windows and like windows arrow glass depending on the operating system, but you also get like this trusted, this trust aspect from the CPU implemented in the FPGA. So like for a start, I would definitely keep the firmware running inside it as simple as possible in order to avoid like making a crash and like avoid like adding a attack surface there. But yeah, of course, like long-term, you might want to add more functionality into it with sufficient isolation of course. Okay, thank you. Okay, the internet is added again. Thanks, just a short question. What about USB keyboards? Yeah, well, depends. Like if you have some means of plugging that into the interceptor, no issue. Like USB is still simple enough that you could implement it with some effort on FPGA like both host and device ports. 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 crypto goggles you mentioned at the beginning, but in a more limited fashion. However, it does seem like there's an opportunity for the solution that you've proposed to have integration points for operating systems like G-Node and CubeSOS and so on and so forth. Do you think that there's another angle? Is 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 in which it can be done. Are there 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 plugged 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 many other ways to do 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 CubeS, I think there's a lot of potential. I mean, I didn't think about that much yet because... Think about like Anti-Evil 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 some of that. I think you could actually integrate into the display manager in order to have like both CubeS 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, okay, whatever. That was my screensaver. Okay, there's another one from the internet. Yeah, what about ciphertext that are longer than what would fit on my screen? Nice question. 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 you would do is you would spread it across different frames. Since the actual pixel bandwidth, the bandwidth for pixel data on a, like even on a low resolution display, like the shitty 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 like stuff it into consecutive frames. You will have some like processing limitations on the FPGA because it's like truly clocked very 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 interceptor, this can be solved. And for the output case, like you just scroll. You just need to wire like the up and down arrows or screen up and screen down keys to like the renderer or something. Thank you. Okay, 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 intercepting your LVDS traffic. Like from my experience, I guess that about 90% 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 don't you suggest an industry standard four times 20 LCD display and just intercept the keyboard line. This would be doable in like one or two days and you could even let it run on an STM32 and no need for an FPGA. But that would be boring, no. Seriously, I think doing the live interception of display data has a serious usability advantage in that you can, like in my laptop use case, I have this, the laptop looks exactly the same as before except for providing me this higher assurance for like certain operations. Like with any kind of external device, I would need to carry that around, need to tether it and then like use two different keyboards and two different displays for 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, considering the development time, yes, intercepting LVDS and embedded display port is a lot of work, but that's not because it's super complex but because it needs to be tuned pretty exactly because you need to take care of a lot of details there, like face alignment and stuff like that. Okay, 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 wire shark listening on the network? I mean, if you have like a some kind of spyware running on your operating system, intercepting for example, GPG or encrypted emails before encryption, you might not actually be able to discern that on even using wire shark if that spyware is any good. Like if it's any good, it will probably be using like some Stegonographic techniques in order to hide its own traffic inside your usual traffic so you can't easily detect it. Okay, thank you. Okay, so I understood your proposal is also for writing email and with that, so if you're hitting on a key, it's doing something, encoding it, encrypting it and putting it in a buffer for the operating system to pick it up, to place it in the application buffer, right? So if that is correct, what kind of encryption do you plan to do on the actual key pressing? So if it's your own public key, 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 Enigmail. So if you open an email, you're typing like the recipient in plain text because that is metadata anyway and then Enigmail 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 key, like the key ID of the recipient as validated by your own signature with the key that in its private, 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 it in there. Okay, we got one time for one more question. Not really a question. I just like, I think you have found a good use case for the touch bar and MacBook Pro. Well, it's good for new too. One more serious question. I missed the beginning of the talk, so is this already like ready? Do you have a prototype ready? I wish. Okay, so 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 control, or you know, control the keyboard and then one control the network so that I can segregate 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 arm socks, like system on a chips because all of them like Broadcom, Qualcomm, Texas Instruments, I've seen some of the insights 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 year running. Like Qualcomm, for example, making arm socks just had like several serious breaches of their hypervisor and trust zone security in the last months. So I think we can basically rule out like any modern arm sock. Well, thanks everybody.