WEBVTT 00:00.000 --> 00:12.360 I'm MC, I'm here to talk about the Teletis Tiki, and I see some of my screen isn't 00:12.360 --> 00:13.360 sharing. 00:13.360 --> 00:15.560 Let's see how this goes. 00:15.560 --> 00:22.080 Here's me hugging a VT 100 terminal as you do, I see a lot of people that can relate 00:22.080 --> 00:29.960 to this, so yeah, and I'm a member of the technical staff at a small company called Teletis 00:29.960 --> 00:30.960 Teletis. 00:30.960 --> 00:36.960 You can reach us as Teletis.se, and you can find my personal webpage on hack.org-MC and 00:36.960 --> 00:41.160 on my Gemini capsule. 00:41.160 --> 00:49.720 This is Cookie, Mulwad VPN's mascot, building some kind of hardware for shadowing here, 00:49.720 --> 00:56.160 because Teletis, the company was born as a part of the trustworthy computing research 00:56.160 --> 00:58.680 team at Mulwad VPN. 00:58.680 --> 01:04.160 And we split into several projects later. 01:04.160 --> 01:11.720 So one company called Lauskler Technique, they inherited the project system transparency, 01:11.720 --> 01:19.560 and this is some transparency log project, and we, Teletis, we are the hardware department. 01:19.560 --> 01:26.680 We have built a computer, it's a very small computer, but it has some fancy features. 01:26.680 --> 01:29.880 You can keep it in your pocket. 01:29.880 --> 01:37.800 So the Teletis TK is a risk-five computer for sensitive computations, with open source software 01:37.800 --> 01:44.800 and open source hardware, and everything is published on GitHub, and this is a link to 01:44.800 --> 01:49.240 our developer handbook where you can read a lot more about it. 01:49.280 --> 01:57.400 You can use the TK for authentication, for signing files, for as a hardware root of trust, 01:57.400 --> 02:02.480 as a random number generator, even signed if you like, which means you can know where 02:02.480 --> 02:08.880 the numbers came from, what the exact device that generated the numbers, and you can use 02:08.880 --> 02:15.840 it for encryption in different ways, and it's, well, it's a general computer, so it's 02:15.840 --> 02:21.720 isolated environment for sensitive computations. 02:21.720 --> 02:27.080 The advantage is that the TK client and the client here, that's what we call what you insert 02:27.080 --> 02:31.760 the TK into a computer or mobile phone. 02:31.760 --> 02:38.320 The client decides the function of the TK by feeding it a device app, a program that it 02:38.320 --> 02:40.000 uploads to it. 02:40.000 --> 02:47.960 So usually there's no need for new hardware, for new function, we just use another application. 02:47.960 --> 02:54.080 Since this is an open platform and we publish everything, including an SDK, you can write 02:54.080 --> 02:58.760 your custom software on it and run your own software on the TK. 02:58.760 --> 03:03.240 There's no storage on the TK that's for sale right now, so there's no risk for persistent 03:03.240 --> 03:08.800 threats because there's storage to store them in, and any secrets in private keys are 03:08.800 --> 03:15.600 not stored on the TK either, so they can't leak in that way. 03:15.600 --> 03:21.200 You can also verify that the TK comes from the vendor with a small program called TK verification, 03:21.200 --> 03:26.240 and you can make your own TK or you have to choose your own basic secret for it, making 03:26.240 --> 03:35.240 it fully use your own, if you like, or you can just buy one from us. 03:35.240 --> 03:38.120 How killer app is the SSH agent? 03:38.120 --> 03:44.840 In the conference open source firmware conference in Gothamburg in 2022, we wanted to show off 03:44.840 --> 03:50.040 the TK and an early version of it and how you can use it. 03:50.040 --> 03:57.160 So we flew together on SSH agent with the excellent go packages for the SSH agent protocol. 03:57.160 --> 04:02.760 It's open SSH compatible, so you can just use ordinary SSH commands with it. 04:02.840 --> 04:10.120 I use it like this, on my system I started TK SSH with a system D user unit, so it starts 04:10.120 --> 04:17.240 automatically when I log in to my laptop, and then I do the SSH command, perhaps I want to 04:17.240 --> 04:24.040 log in to a server, I want to sign a git commit, or I want to get clone something from 04:24.040 --> 04:32.440 GitHub or GitHub or something with SSH, and the agent automatically loads a small device app 04:32.520 --> 04:37.640 into the TK, we call it the signer, and it's a small elliptic curve signature program. 04:38.520 --> 04:45.560 And the TK starts to blink the state this led, indicating that I should assert my presence, 04:45.560 --> 04:51.720 I touch this touch sensor, and I mean, just like any other security token. 04:53.720 --> 04:59.640 But this is not the security token, this is a general computer, so how can you trust it? 05:02.920 --> 05:09.000 Think about that for a moment. If someone writes a malicious program and feeds that program into 05:09.000 --> 05:16.920 the TK instead, won't that program leak the secrets? But here's the nice thing with this thing. 05:17.800 --> 05:24.520 Whatever you don't share anything between that, and whatever we instead base all our secrets 05:24.600 --> 05:35.240 on a measurement of the app on the TK. This way a malicious app won't leak any other app 05:35.240 --> 05:46.120 secrets, it will leak only its own secrets, which are always different. This is the measured boot system. 05:46.520 --> 05:56.040 We use a mutable code on ROM, a small firmware we have, to always measure any app that is going 05:56.040 --> 06:04.120 to be started. And we mix in hardware secret that is unique for this particular device. Every device 06:04.120 --> 06:11.160 has a unique secret base hardware secret. We mix in this and we get a new identity. This identity, 06:11.800 --> 06:22.200 you can base all your secrets or different key pairs and key material on. This is inspired by 06:22.200 --> 06:29.640 trustworthy computing group's dice, but it was a really called write at Microsoft Research, 06:29.640 --> 06:37.240 great name. So the advantages of this is that the software integrity is always guaranteed. 06:37.240 --> 06:42.920 Change one bit of the binary in the device app and the entire identity and the base of all 06:42.920 --> 06:52.360 your secret key material is changed. So this secret material that can be generate key material 06:52.360 --> 06:57.480 for you, for instance, the SSH private key. And these private keys are not stored, 06:57.480 --> 07:02.520 persistently on the TK. They are re-generated every time on that particular TK running 07:02.520 --> 07:08.760 that particular binary. Which also means that there is an unlimited number of these secret keys 07:08.760 --> 07:13.880 because there is nothing stored. If you want more secret keys, you can just generate them by adding 07:13.880 --> 07:19.640 extra entropy from the client. And that will be mixed in and get a new key material. 07:21.080 --> 07:25.320 And of course the secrets themselves don't leak between applications because they are totally 07:25.400 --> 07:36.200 lost when you, if power is not present, then everything is forgotten, hopefully. 07:38.920 --> 07:44.760 So this is different from verified boot, which is usually called a secure boot in the PC world. 07:44.920 --> 07:56.600 And in verified boot scenario, every app that this boot has to be signed, a blessed app 07:56.600 --> 08:03.240 signed by the vendor. And this is totally unacceptable for us. So forced verified boot is unacceptable 08:03.240 --> 08:07.160 because this is an open platform we want to be able to run, whatever. 08:07.720 --> 08:17.880 So this measured boot is considered like this. We call the result of the measured boot 08:17.880 --> 08:28.040 compound device identity. It's a function that's described here. So we take the hash 08:28.040 --> 08:36.360 digest of the entire application before it started. We mix that in with a new hash digest of 08:36.360 --> 08:42.840 the unique device secret, which is something in the hardware, something to use or hats, that unique 08:42.840 --> 08:50.520 TK. And we mix it in with something called the user supplied secret with a hash of typically a 08:50.520 --> 08:56.040 pass phrase that the user types on the client, the laptop or whatever. And we mix that's something 08:56.120 --> 09:05.080 to use in notes. And then we fill all this together in a new Blake to S operation. And we get 09:05.080 --> 09:10.920 the CDI, the compound device identity, mix together by the unique device secret, the application 09:10.920 --> 09:18.760 digest and the user supplied secret. That's the CDI. That's the base of all secrets for that 09:18.760 --> 09:24.040 particular application. The application itself doesn't have access to the unique device secret. 09:24.920 --> 09:32.280 So it can't reveal the base hardware secret to anyone. It only has access to the CDI. 09:35.080 --> 09:41.160 Let's talk about the hardware for a moment. On the right side, there's a USB-C connector 09:41.720 --> 09:49.080 on the left side. There's touch sensor and there's a large ship in between and that's the FPDA. 09:49.800 --> 09:56.760 I guess most of this crowd knows what an FPDA is, but bear with me, an FPDA is a chip that you can 09:56.760 --> 10:05.800 configure inside it to appear to be another ship. And our hardware design is inside that ship 10:05.800 --> 10:11.160 locked down inside an internal memory with a blown fuse so you can't read it out again. 10:11.160 --> 10:15.240 This is important because the unique device secret is a part of the hardware design. 10:15.240 --> 10:24.680 Everyone, don't want to leak that. Some specs. We had a 32-bit risk 5 CPU. It's a soft core 10:24.680 --> 10:33.320 inside FPDA. We use clarin wolf's PQRV32 for this. There's some RAM. We have some hardware 10:33.320 --> 10:39.240 cores around the CPU, which is memory mapped. And there's two execution modes, firmware mode, 10:39.240 --> 10:45.720 an application mode. This means that an application mode, most of the memory is not 10:45.720 --> 10:53.800 rightable anymore or not visible anymore, especially sensitive stuff like the UDS. It's not visible 10:53.800 --> 11:00.680 at all. There's no interrupts in this design. So it's easy to reason about where the code is at 11:00.680 --> 11:08.520 any given time. And as I said earlier, there's no persistent storage. Except there is a small flash 11:08.600 --> 11:15.400 on the PCB, which is useful during hardware development. You can store the FPDA bit stream 11:15.400 --> 11:20.120 on the flash during hardware development if you like. And you start for development. 11:20.840 --> 11:27.320 But when you store it inside FPDA and load the fuse, you can't access the flash anymore. 11:28.120 --> 11:32.760 There's no operating system. You're on your own. We provide some sea libraries and stuff, 11:32.760 --> 11:42.760 but there's operating system at all. This is bare metal. For the actual design, we decided 11:42.760 --> 11:49.320 to use only open source tools. And only documented or reverse engineer the FPDA chips, which kind of 11:49.320 --> 11:59.960 limits our choice of FPDA. And we use EOSIS and NXPINAR. We use ISTORM and we develop some of our 12:00.520 --> 12:09.080 programming tools of selfs. And mostly very long for the hardware design. And KaiKad for PCB 12:09.080 --> 12:15.080 design and everything is published and open source license. So please do something with it. 12:16.360 --> 12:22.920 The FPDA chip itself is a lattice size 40 family, which has had already good support in open source 12:22.920 --> 12:29.640 tools. But importantly, it has lockable internal configuration memory, which means we can lock 12:30.600 --> 12:36.280 down the bitstreme and the all important unique device secret inside the chip. 12:37.880 --> 12:44.440 This has, this dies 40 hours, kind of limited resources. So it's challenged to fit the entire design 12:44.440 --> 12:51.240 into it. But we're paying for reversing other chips. Oh, shit. Okay. 12:52.200 --> 13:01.240 All right. Okay. Well, this is supposed to be an illustration on what's inside the FPDA. And 13:01.240 --> 13:07.400 as you can see on the front, above there's the CPU. There's some ROM where the bootloader is. 13:08.040 --> 13:13.240 There's some firmware RAM. Only available for the firmware. There's the unique device secret. 13:13.240 --> 13:21.080 And on the bottom, there's a long other things, a timer. There's a UART for communication with 13:21.080 --> 13:27.080 the client. No interrupts, remember? So this, you have to pull this UART for just to read or write 13:27.080 --> 13:34.040 something at all. There's also a true random number generator here, a touch sensor control. 13:35.000 --> 13:41.080 There's also something called a TK1 core. An inside a TK1 core, there's something called the 13:41.080 --> 13:48.360 security monitor. And in modern chips, as you know, the actual CPU has some of these functions. 13:48.440 --> 13:55.000 You can mark some of the memory non-executable for instance. And you can mark, you can have 13:55.000 --> 14:01.480 memory access control in different ways. But this simple CPU we use doesn't have anything of that. 14:01.480 --> 14:08.760 So instead, we implemented on the side and memory map the entire thing. And this is available for 14:08.760 --> 14:16.680 the apps to use. And if they register the stack for instance as non-executable and the CPU tries 14:16.760 --> 14:25.160 to execute something from the stack, we immediately stopped the CPU by feeding it in a legal instruction. 14:25.160 --> 14:32.920 And we get internal, eternal, blinking red light made by hardware, no further execution is done. 14:34.120 --> 14:43.800 So this is one of the things that supports us. This is part of the first actual program that 14:43.880 --> 14:51.960 ever ran on the TK, as loaded by the bootloader. This is the assembly program I wrote, 14:51.960 --> 14:58.360 and it's blinking the led in a lot of lights. Different colors, but it was a good day at work when 14:58.360 --> 15:04.600 this finally worked because a lot of things just worked then. So let's talk a little more about 15:04.600 --> 15:10.040 our software and not just a small assembly program. We have an emulator, it's a friendly fork of 15:10.040 --> 15:17.960 QMU, that you can use to develop stuff even if you don't have a TK yet. We have a simple bootloader 15:17.960 --> 15:25.480 inside the bitstream in the ROM. It says 4k or so, it doesn't do much. It just allows you to load a new app 15:25.480 --> 15:32.120 into the TK, measure it and jump straight. There's some client applications, there's a Sage agent 15:32.120 --> 15:39.400 and I will talk about the TK verification to verify that the TK you got in the mail is the same 15:39.400 --> 15:46.840 that we saw. The TK sign tool that is used to sign files, the TK random generated, which gives 15:46.840 --> 15:52.840 quite a good random numbers. And of course, they're corresponding device applications running on 15:52.840 --> 15:59.480 the actual TKs. To develop software on the client, we have some go packages, a Python module, 15:59.480 --> 16:07.080 and our intern command wrote some Java stuff, and then to develop stuff on the actual TK, 16:07.240 --> 16:14.360 we have some device libraries in C, and our architecture is supported from LLVM 15 and forward, 16:14.360 --> 16:21.320 which means that everything in front of LLVM should be able to make something work on the TK. 16:22.760 --> 16:28.520 And then we have some OCI images like the TK builder and the QMU image. If you don't want to install 16:28.520 --> 16:36.680 anything, you can just use the Docker images. Some external software, more people have written stuff 16:36.680 --> 16:42.920 for us. So we have Danny, who has written some rust libraries to do device application development 16:42.920 --> 16:49.720 in rust, and we have some client libraries in TypeScript for actually using it from web browser with 16:49.720 --> 16:56.520 web serial, and there's been experimental bring-up of Zig Morton somewhere here. 16:58.200 --> 17:06.040 The one of them and Mikael Ogrin did this independently, and then we have Ron Evans, who actually added 17:06.120 --> 17:13.400 support for TK in a tiny girl. And then we have, last but not least, the TK, 17:13.400 --> 17:20.200 Aga plugin, a plugin to the Aga encryption tool, Aga's nice encryption tool, my fillet, 17:20.200 --> 17:25.640 fillet proposal, and Daniel LeBlin did that. And all the main projects are listed down on our developer 17:25.640 --> 17:35.480 handbook. The PCBs themselves are assembled in Sweden. The FPGA is provisioned in our office in 17:35.560 --> 17:41.720 Rothenberg in an air-depth environment. And as I said, the TK, when you get it in mail, 17:41.720 --> 17:48.440 can be verified that it's the same that we saw, at least it's part of it. And that's the supply chain. 17:49.640 --> 17:57.160 We also sell TK unlocked, which is an un-provisioned TK. If you want to choose 17:57.160 --> 18:01.480 basically to yourself, or if you want to experiment with in Verilog or in other design, 18:01.480 --> 18:07.160 you can buy the TK unlocked. Then you also need a programming board, which looks like this, 18:07.960 --> 18:12.520 and we sell that as well. Or you can build your own for our drawings. 18:13.720 --> 18:20.200 The status is the first official hardware release was in March 23. You can buy the TK, the TK 18:20.200 --> 18:25.720 unlocked and the TK board program report on our webchop. We have several client apps available 18:25.720 --> 18:32.040 for Linux, Mac OS, and Windows, or reproducible builds for a lot of stuff, not necessarily on 18:32.040 --> 18:39.080 Mac OS. I'm sorry. The device verification service is up running and everything is on GitHub. 18:41.000 --> 18:46.680 In the future, we are writing more apps and supporting more use cases, but we would like 18:46.680 --> 18:53.240 you to do that, because we're focusing on developing the new hardware generation, which we'll have 18:53.320 --> 19:03.000 native USB-HID think posky. Fighter, where the system reset from device, and a secure persistent 19:03.000 --> 19:09.160 storage kind of hard to get right, and an extended memory access control, and much faster communication 19:09.160 --> 19:19.320 with a client, and increasing the frequency of the CPU. Even later, we will release a smaller version, 19:19.320 --> 19:26.040 that's possible to keep in your laptop all the time. Possibly, some way into the future 19:26.040 --> 19:31.320 a version with biometrics instead of just touch, and if I do two app, we have some experiments with 19:31.320 --> 19:36.520 us, but it's not very polished yet, but it's sort of kind of works, and we are, of course, 19:36.520 --> 19:43.320 looking at other FPGA chips. Our friend Yurikim has already done this for a lot of things, and he took 19:43.400 --> 19:51.160 the cryptic hardware security model, firmware, and used it on a Tiki design on an ECP5, 19:51.160 --> 19:58.680 and much larger FPGA. We would also like to think about this as a trust anchor in a much bigger 19:58.680 --> 20:06.280 computer, think a laptop, think TPM, but much, much simpler. That would be awesome, and I would 20:06.280 --> 20:12.280 help anyone who wants to work on that. So, in summary, we have a new wrist fly computer, we're 20:12.360 --> 20:17.160 interesting hardware features, in a USB-Stick form factor. With no persistence state, 20:17.160 --> 20:21.320 that uses measured boot to create unique identities based on what the user has, 20:21.320 --> 20:25.320 what do you use in Earth, and the software integrity of this software running on it. 20:25.960 --> 20:31.480 Client on device SDKs are available, there's a custom message agent and go, and some other 20:31.480 --> 20:40.200 nice client apps available. Devices are usable, from production to end users, and it's all under 20:40.280 --> 20:46.280 our licenses, and we have a list of all known products, please increase that in the list. 20:48.280 --> 20:58.920 And you can reach us at TiliTis.se, we are on IRC and on Matrix, and there's the list of contact 20:58.920 --> 21:00.920 information. Thank you. 21:01.160 --> 21:09.160 APPLAUSE 21:09.800 --> 21:17.000 Four minutes for questions. How are you dealing with something you have to update your app? 21:17.800 --> 21:23.640 Very good question. I purposely left that out of all this presentation, because I knew someone 21:23.640 --> 21:31.640 would get it. Well, I said, forced verified boot is unacceptable, would voluntarily 21:31.640 --> 21:37.080 using verified boot by shaming two apps, is quite okay, and a solution to that problem. 21:37.080 --> 21:44.360 So, first, you start one app, which verifies the next step. That's so 21:44.360 --> 21:50.040 impossible with the current generation, and I have a phone together, a profile concept that does 21:50.120 --> 21:57.080 exactly this is called Tiki device loader. You can find it in GitHub, and that works, 21:57.080 --> 22:01.320 but it's kind of crunchy, and I flew it together during a hackathon. But in the coming 22:01.320 --> 22:08.200 generation, we will have support in the firmware for this, so we can guarantee the identity kept 22:08.200 --> 22:14.600 is kept the same for an updated version of, for instance, the signer. Yes. Thank you. 22:20.920 --> 22:28.840 Now, we want to guarantee a lot of stuff by using our own hardware design, because most of 22:28.840 --> 22:37.560 it is, especially the UDS, it's locked down inside the hardware design, and using something 22:37.560 --> 22:41.560 like a microcontroller or something would make this impossible. 22:41.560 --> 23:00.360 Yes, it is. If you have an ARGF environment, for instance, we publish signatures of stuff, 23:00.360 --> 23:07.400 and if you download that and bring it to the ARGF environment, and then do your 23:07.400 --> 23:12.440 verification, it's quite possible today. And this is another completely other talk, and you should 23:12.440 --> 23:22.520 watch my talk at Stackelm last year to get an idea on how this verification works. This is part of it. 23:22.760 --> 23:31.000 Yeah. Yeah. 23:31.000 --> 23:37.160 Is it possible to buy a TQ with the same hardware identifier as a team, so have a backup? 23:37.160 --> 23:42.920 You can't buy it from us, but you can buy the TQ unlocked and flash it yourself with the same 23:42.920 --> 23:49.640 identity on both of them, and it's easy to do, and you don't have to rebuild entire things. 23:49.640 --> 23:59.720 You can just patch in the different UDS. So, yeah, that's a very good idea, because if you don't, 23:59.720 --> 24:03.720 if you lose your TQ or something and you're locked out and stuff them, yeah. 24:03.720 --> 24:08.760 And more questions, otherwise I have one. 24:08.760 --> 24:15.880 You said there were difficult to do persistent storage attacks, but there is persistent storage. 24:16.840 --> 24:24.760 No, no, no, it's not difficult to do persistent storage attacks. It's difficult to do persistent 24:24.760 --> 24:30.120 storage on the coming generation to actually implement it. Currently. 24:30.120 --> 24:35.480 Thinking the current generation now, it had persistent storage, but you've used it. 24:36.200 --> 24:41.560 So, I have to trust that the hardware is the fused protection works. 24:41.560 --> 24:48.600 Yes. Yeah, but that's inside the lattice size 40s, so you have to trust the lattice manufacturing 24:48.600 --> 24:54.680 process. Yes. And you can verify that it's actually a lattice size 40 by using some other 24:54.680 --> 25:04.440 design on it first, which the attacker would presumably have a large problem trying to figure 25:04.440 --> 25:07.240 out what kind of tests you would do to the chip. 25:12.440 --> 25:12.920 Thanks, Mike. 25:21.640 --> 25:24.120 Thanks.