I'm MC, I'm here to talk about the Teletis Tiki, and I see some of my screen isn't
sharing.
Let's see how this goes.
Here's me hugging a VT 100 terminal as you do, I see a lot of people that can relate
to this, so yeah, and I'm a member of the technical staff at a small company called Teletis
Teletis.
You can reach us as Teletis.se, and you can find my personal webpage on hack.org-MC and
on my Gemini capsule.
This is Cookie, Mulwad VPN's mascot, building some kind of hardware for shadowing here,
because Teletis, the company was born as a part of the trustworthy computing research
team at Mulwad VPN.
And we split into several projects later.
So one company called Lauskler Technique, they inherited the project system transparency,
and this is some transparency log project, and we, Teletis, we are the hardware department.
We have built a computer, it's a very small computer, but it has some fancy features.
You can keep it in your pocket.
So the Teletis TK is a risk-five computer for sensitive computations, with open source software
and open source hardware, and everything is published on GitHub, and this is a link to
our developer handbook where you can read a lot more about it.
You can use the TK for authentication, for signing files, for as a hardware root of trust,
as a random number generator, even signed if you like, which means you can know where
the numbers came from, what the exact device that generated the numbers, and you can use
it for encryption in different ways, and it's, well, it's a general computer, so it's
isolated environment for sensitive computations.
The advantage is that the TK client and the client here, that's what we call what you insert
the TK into a computer or mobile phone.
The client decides the function of the TK by feeding it a device app, a program that it
uploads to it.
So usually there's no need for new hardware, for new function, we just use another application.
Since this is an open platform and we publish everything, including an SDK, you can write
your custom software on it and run your own software on the TK.
There's no storage on the TK that's for sale right now, so there's no risk for persistent
threats because there's storage to store them in, and any secrets in private keys are
not stored on the TK either, so they can't leak in that way.
You can also verify that the TK comes from the vendor with a small program called TK verification,
and you can make your own TK or you have to choose your own basic secret for it, making
it fully use your own, if you like, or you can just buy one from us.
How killer app is the SSH agent?
In the conference open source firmware conference in Gothamburg in 2022, we wanted to show off
the TK and an early version of it and how you can use it.
So we flew together on SSH agent with the excellent go packages for the SSH agent protocol.
It's open SSH compatible, so you can just use ordinary SSH commands with it.
I use it like this, on my system I started TK SSH with a system D user unit, so it starts
automatically when I log in to my laptop, and then I do the SSH command, perhaps I want to
log in to a server, I want to sign a git commit, or I want to get clone something from
GitHub or GitHub or something with SSH, and the agent automatically loads a small device app
into the TK, we call it the signer, and it's a small elliptic curve signature program.
And the TK starts to blink the state this led, indicating that I should assert my presence,
I touch this touch sensor, and I mean, just like any other security token.
But this is not the security token, this is a general computer, so how can you trust it?
Think about that for a moment. If someone writes a malicious program and feeds that program into
the TK instead, won't that program leak the secrets? But here's the nice thing with this thing.
Whatever you don't share anything between that, and whatever we instead base all our secrets
on a measurement of the app on the TK. This way a malicious app won't leak any other app
secrets, it will leak only its own secrets, which are always different. This is the measured boot system.
We use a mutable code on ROM, a small firmware we have, to always measure any app that is going
to be started. And we mix in hardware secret that is unique for this particular device. Every device
has a unique secret base hardware secret. We mix in this and we get a new identity. This identity,
you can base all your secrets or different key pairs and key material on. This is inspired by
trustworthy computing group's dice, but it was a really called write at Microsoft Research,
great name. So the advantages of this is that the software integrity is always guaranteed.
Change one bit of the binary in the device app and the entire identity and the base of all
your secret key material is changed. So this secret material that can be generate key material
for you, for instance, the SSH private key. And these private keys are not stored,
persistently on the TK. They are re-generated every time on that particular TK running
that particular binary. Which also means that there is an unlimited number of these secret keys
because there is nothing stored. If you want more secret keys, you can just generate them by adding
extra entropy from the client. And that will be mixed in and get a new key material.
And of course the secrets themselves don't leak between applications because they are totally
lost when you, if power is not present, then everything is forgotten, hopefully.
So this is different from verified boot, which is usually called a secure boot in the PC world.
And in verified boot scenario, every app that this boot has to be signed, a blessed app
signed by the vendor. And this is totally unacceptable for us. So forced verified boot is unacceptable
because this is an open platform we want to be able to run, whatever.
So this measured boot is considered like this. We call the result of the measured boot
compound device identity. It's a function that's described here. So we take the hash
digest of the entire application before it started. We mix that in with a new hash digest of
the unique device secret, which is something in the hardware, something to use or hats, that unique
TK. And we mix it in with something called the user supplied secret with a hash of typically a
pass phrase that the user types on the client, the laptop or whatever. And we mix that's something
to use in notes. And then we fill all this together in a new Blake to S operation. And we get
the CDI, the compound device identity, mix together by the unique device secret, the application
digest and the user supplied secret. That's the CDI. That's the base of all secrets for that
particular application. The application itself doesn't have access to the unique device secret.
So it can't reveal the base hardware secret to anyone. It only has access to the CDI.
Let's talk about the hardware for a moment. On the right side, there's a USB-C connector
on the left side. There's touch sensor and there's a large ship in between and that's the FPDA.
I guess most of this crowd knows what an FPDA is, but bear with me, an FPDA is a chip that you can
configure inside it to appear to be another ship. And our hardware design is inside that ship
locked down inside an internal memory with a blown fuse so you can't read it out again.
This is important because the unique device secret is a part of the hardware design.
Everyone, don't want to leak that. Some specs. We had a 32-bit risk 5 CPU. It's a soft core
inside FPDA. We use clarin wolf's PQRV32 for this. There's some RAM. We have some hardware
cores around the CPU, which is memory mapped. And there's two execution modes, firmware mode,
an application mode. This means that an application mode, most of the memory is not
rightable anymore or not visible anymore, especially sensitive stuff like the UDS. It's not visible
at all. There's no interrupts in this design. So it's easy to reason about where the code is at
any given time. And as I said earlier, there's no persistent storage. Except there is a small flash
on the PCB, which is useful during hardware development. You can store the FPDA bit stream
on the flash during hardware development if you like. And you start for development.
But when you store it inside FPDA and load the fuse, you can't access the flash anymore.
There's no operating system. You're on your own. We provide some sea libraries and stuff,
but there's operating system at all. This is bare metal. For the actual design, we decided
to use only open source tools. And only documented or reverse engineer the FPDA chips, which kind of
limits our choice of FPDA. And we use EOSIS and NXPINAR. We use ISTORM and we develop some of our
programming tools of selfs. And mostly very long for the hardware design. And KaiKad for PCB
design and everything is published and open source license. So please do something with it.
The FPDA chip itself is a lattice size 40 family, which has had already good support in open source
tools. But importantly, it has lockable internal configuration memory, which means we can lock
down the bitstreme and the all important unique device secret inside the chip.
This has, this dies 40 hours, kind of limited resources. So it's challenged to fit the entire design
into it. But we're paying for reversing other chips. Oh, shit. Okay.
All right. Okay. Well, this is supposed to be an illustration on what's inside the FPDA. And
as you can see on the front, above there's the CPU. There's some ROM where the bootloader is.
There's some firmware RAM. Only available for the firmware. There's the unique device secret.
And on the bottom, there's a long other things, a timer. There's a UART for communication with
the client. No interrupts, remember? So this, you have to pull this UART for just to read or write
something at all. There's also a true random number generator here, a touch sensor control.
There's also something called a TK1 core. An inside a TK1 core, there's something called the
security monitor. And in modern chips, as you know, the actual CPU has some of these functions.
You can mark some of the memory non-executable for instance. And you can mark, you can have
memory access control in different ways. But this simple CPU we use doesn't have anything of that.
So instead, we implemented on the side and memory map the entire thing. And this is available for
the apps to use. And if they register the stack for instance as non-executable and the CPU tries
to execute something from the stack, we immediately stopped the CPU by feeding it in a legal instruction.
And we get internal, eternal, blinking red light made by hardware, no further execution is done.
So this is one of the things that supports us. This is part of the first actual program that
ever ran on the TK, as loaded by the bootloader. This is the assembly program I wrote,
and it's blinking the led in a lot of lights. Different colors, but it was a good day at work when
this finally worked because a lot of things just worked then. So let's talk a little more about
our software and not just a small assembly program. We have an emulator, it's a friendly fork of
QMU, that you can use to develop stuff even if you don't have a TK yet. We have a simple bootloader
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
into the TK, measure it and jump straight. There's some client applications, there's a Sage agent
and I will talk about the TK verification to verify that the TK you got in the mail is the same
that we saw. The TK sign tool that is used to sign files, the TK random generated, which gives
quite a good random numbers. And of course, they're corresponding device applications running on
the actual TKs. To develop software on the client, we have some go packages, a Python module,
and our intern command wrote some Java stuff, and then to develop stuff on the actual TK,
we have some device libraries in C, and our architecture is supported from LLVM 15 and forward,
which means that everything in front of LLVM should be able to make something work on the TK.
And then we have some OCI images like the TK builder and the QMU image. If you don't want to install
anything, you can just use the Docker images. Some external software, more people have written stuff
for us. So we have Danny, who has written some rust libraries to do device application development
in rust, and we have some client libraries in TypeScript for actually using it from web browser with
web serial, and there's been experimental bring-up of Zig Morton somewhere here.
The one of them and Mikael Ogrin did this independently, and then we have Ron Evans, who actually added
support for TK in a tiny girl. And then we have, last but not least, the TK,
Aga plugin, a plugin to the Aga encryption tool, Aga's nice encryption tool, my fillet,
fillet proposal, and Daniel LeBlin did that. And all the main projects are listed down on our developer
handbook. The PCBs themselves are assembled in Sweden. The FPGA is provisioned in our office in
Rothenberg in an air-depth environment. And as I said, the TK, when you get it in mail,
can be verified that it's the same that we saw, at least it's part of it. And that's the supply chain.
We also sell TK unlocked, which is an un-provisioned TK. If you want to choose
basically to yourself, or if you want to experiment with in Verilog or in other design,
you can buy the TK unlocked. Then you also need a programming board, which looks like this,
and we sell that as well. Or you can build your own for our drawings.
The status is the first official hardware release was in March 23. You can buy the TK, the TK
unlocked and the TK board program report on our webchop. We have several client apps available
for Linux, Mac OS, and Windows, or reproducible builds for a lot of stuff, not necessarily on
Mac OS. I'm sorry. The device verification service is up running and everything is on GitHub.
In the future, we are writing more apps and supporting more use cases, but we would like
you to do that, because we're focusing on developing the new hardware generation, which we'll have
native USB-HID think posky. Fighter, where the system reset from device, and a secure persistent
storage kind of hard to get right, and an extended memory access control, and much faster communication
with a client, and increasing the frequency of the CPU. Even later, we will release a smaller version,
that's possible to keep in your laptop all the time. Possibly, some way into the future
a version with biometrics instead of just touch, and if I do two app, we have some experiments with
us, but it's not very polished yet, but it's sort of kind of works, and we are, of course,
looking at other FPGA chips. Our friend Yurikim has already done this for a lot of things, and he took
the cryptic hardware security model, firmware, and used it on a Tiki design on an ECP5,
and much larger FPGA. We would also like to think about this as a trust anchor in a much bigger
computer, think a laptop, think TPM, but much, much simpler. That would be awesome, and I would
help anyone who wants to work on that. So, in summary, we have a new wrist fly computer, we're
interesting hardware features, in a USB-Stick form factor. With no persistence state,
that uses measured boot to create unique identities based on what the user has,
what do you use in Earth, and the software integrity of this software running on it.
Client on device SDKs are available, there's a custom message agent and go, and some other
nice client apps available. Devices are usable, from production to end users, and it's all under
our licenses, and we have a list of all known products, please increase that in the list.
And you can reach us at TiliTis.se, we are on IRC and on Matrix, and there's the list of contact
information. Thank you.
APPLAUSE
Four minutes for questions. How are you dealing with something you have to update your app?
Very good question. I purposely left that out of all this presentation, because I knew someone
would get it. Well, I said, forced verified boot is unacceptable, would voluntarily
using verified boot by shaming two apps, is quite okay, and a solution to that problem.
So, first, you start one app, which verifies the next step. That's so
impossible with the current generation, and I have a phone together, a profile concept that does
exactly this is called Tiki device loader. You can find it in GitHub, and that works,
but it's kind of crunchy, and I flew it together during a hackathon. But in the coming
generation, we will have support in the firmware for this, so we can guarantee the identity kept
is kept the same for an updated version of, for instance, the signer. Yes. Thank you.
Now, we want to guarantee a lot of stuff by using our own hardware design, because most of
it is, especially the UDS, it's locked down inside the hardware design, and using something
like a microcontroller or something would make this impossible.
Yes, it is. If you have an ARGF environment, for instance, we publish signatures of stuff,
and if you download that and bring it to the ARGF environment, and then do your
verification, it's quite possible today. And this is another completely other talk, and you should
watch my talk at Stackelm last year to get an idea on how this verification works. This is part of it.
Yeah. Yeah.
Is it possible to buy a TQ with the same hardware identifier as a team, so have a backup?
You can't buy it from us, but you can buy the TQ unlocked and flash it yourself with the same
identity on both of them, and it's easy to do, and you don't have to rebuild entire things.
You can just patch in the different UDS. So, yeah, that's a very good idea, because if you don't,
if you lose your TQ or something and you're locked out and stuff them, yeah.
And more questions, otherwise I have one.
You said there were difficult to do persistent storage attacks, but there is persistent storage.
No, no, no, it's not difficult to do persistent storage attacks. It's difficult to do persistent
storage on the coming generation to actually implement it. Currently.
Thinking the current generation now, it had persistent storage, but you've used it.
So, I have to trust that the hardware is the fused protection works.
Yes. Yeah, but that's inside the lattice size 40s, so you have to trust the lattice manufacturing
process. Yes. And you can verify that it's actually a lattice size 40 by using some other
design on it first, which the attacker would presumably have a large problem trying to figure
out what kind of tests you would do to the chip.
Thanks, Mike.
Thanks.