TKey – Security for the New World
tillitis.se
tillitis.se
There's also Glasklar Teknik AB and Karlstad Internet Privacy Lab AB.
Glasklar does:
- Sigsum, a transparency log design
- System Transparency, a security architecture for transparent systems
- Hosts and maintains the Debian Snapshot service, an archive of the past decade of released Debian packages
KIPL does traffic analysis defense against AI-based classifiers, which Mullvad recently integrated into the VPN app.
They're a model company for data-minimization. No account names, no passwords, can pay by cash in an envelope, RAM-only infrastructure, thorough and frequent 3rd-party auditing, etc.
They provide back, fund privacy initiatives, have a history of being unable to provide user data when requested by governments, all of their stuff is well documented. You'd be hard-pressed to find anyone privacy & security conscious speak poorly about them.
There are 6 other providers that do offer static IP, and one of those uses AWS nitro to ensure that mappings aren't available to LEO. So this wasn't a technical limitation.
What were they deceptive about? Their announcement is straight forward.
"Regrettably individuals have frequently used this feature to host undesirable content and malicious services from ports that are forwarded from our VPN servers. This has led to law enforcement contacting us, our IPs getting blacklisted, and hosting providers cancelling us.
The result is that it affects the majority of our users negatively, because they cannot use our service without having services being blocked."
https://mullvad.net/en/blog/removing-the-support-for-forward...
I'm not saying you have to agree with the decision, but I don't see any deception. They even gave a months notice.
https://web.archive.org/web/20230530003202/https://mullvad.n...
But if I may put my cynical hat on (I think this is fair for any VPN provider), mullvad states in HN[0]
> Port forwarding needed to be removed on moral grounds.
Fair enough, however such moral grounds only came to light when extreme and immediate pressure was applied to their business model. The same post does talk about abuse, but only in terms of how it created a negative experience for "some" users (no details). The blog post does go into those negative effects, good, and doesn't try to whitewash it in moral reasons, also good. I think I mistook the official blog with an official statement here on HN.
There was another HN post apparently by a mullvad engineer that didn't pull any punches. I can't find it anymore, but I remember that it was that post that somehow led me to kfred's post and then left a very bad taste in my mouth. Maybe someone else is a better researcher than me and can dig it up.
I'll retract my "character" criticism, since mullvad clearly cares deeply about privacy, regardless of my perceived problems with their public communications.
Personally, iCloud Private Relay ticks all the boxes for my use cases, so I should have just kept my mouth shut.
Turns out, there is no such thing as "stored secrets", and the device has no non-volatile memory at all, other than FPGA configuration (NVCM). The only secret is UDS, 256 random bits that are baked into FPGA configuration stream, and they are protected by FPGA's read-out protection. The mechanism that is normally used to prevent device duplication is instead used to protect cryptographic secrets. Replacing bitstream is all-or-nothing affair, so a hypothetical "CPU with debug capabilities" will not have access to UDS.
This means all storage must be on PC and some classes of things are are absolutely impossible - for example an anti-bruteforce counter that clears secrets if too many wrong attempts are entered.
> FPGA configuration (NVCM). The only secret is UDS, 256 random bits that are baked into FPGA configuration stream, and they are protected by FPGA's read-out protection.
Correct. Here are some more interesting details:
- we're using the Lattice iCE40 UltraPlus FPGA, which is supported by open tooling and has been for a long time. During the course of the project we also had the configuration and locking protocol reverse engineered so that one can configure and lock the FPGA with open tooling.
- the iCE40's Non-Volatile Configuration Memory (NVCM) uses anti-fuse technology for storing the configuration bits, where the 0s and 1s are stored in vias on the die. The physics of how these vias are modified to represent a 0 or a 1 make it very hard to read out information using X-ray, unlike on-die storage implemented using "horizontal" e-fuses. That's the gist of it.
- the FPGA's boot state machine is unfortunately designed such that you can get it to boot an external bitstream from SPI even after you've configured and locked NVCM, and the state of EBRs (block memory) is retained across warm reboots of the FPGA. We took several steps to mitigate this limitation, which, now that I think about it, would make several interesting blog posts. The UDS memory itself is in LCs, you can mix in key material from the host, the exact timing of that is randomized, RAM (implemented in EBR) is has both address and data randomization... and a few more things.
- physical security is hard, and the TKey won't be able to stand up against any and all physical attacks, but I don't think there is any security hardware in the world that is as open and inspectable as the TKey.
It's just the counter that is impossible.
2023 (204 points, 78 comments) https://news.ycombinator.com/item?id=38764353
2022 (305 points, 119 comments) https://news.ycombinator.com/item?id=32896580
Note they've had a couple of security vulnerabilities https://news.ycombinator.com/item?id=39830553 https://news.ycombinator.com/item?id=40055726
Dude. Can I borrow your time machine?
Yes, OpenTitan is cool.
The philosophical discussion about FPGAs and ASICs in the context of security is interesting.
For the TKey FPGA design you can inspect both the design (https://github.com/tillitis/tillitis-key1/tree/main/hw/appli...) and the toolchain (Icestorm: https://github.com/tillitis/tillitis-key1/blob/main/doc/tool... that contains synthesis, place&route, NVCM programming tools). However, the internal FPGA fabric—consisting of the logic cells, memory, and interconnects—remains proprietary.
Most Open Source ASICs I am aware of provide open-source RTL designs, but the tool chains are usually proprietary. Hard macros, memories, security mechanisms, etc are typically also closed source. And then there is the manufacturing process itself that is not transparent.
There isn’t a definitive answer as to what constitutes “enough” openness for security inspections. Individuals have different thresholds for what they consider acceptable.
So far we chose as much open source as possible.
theoretically this is quite desirable but various protocols aren't build in a way enabling it
e.g. TOTP pushes a secret from the server to the client, instead of having some form of deterministic key exchange
similar while FIDO protocols and passkeys could have been designed in a way which can work fully stateless they are not
now it doesn't mean you can't make it work with tkeys but it can get more complex e.g. for TOTP using TKey to guard a local password vault which then does the TOTP instead of having the TOTP on the key directly (but then while TOTP is better then SMS 2FA it's still pretty bad compared to what technically is possible, like much worse then a lot of people realize)
It's been a while since I've looked deeply at FIDO, but I think they would have had to make a handful of nontrivial security concessions to make WebAuthn stateless. One pretty important one that comes to mind is the token counter, which in principal enables RPs to detect a cloned credential.
If you only do user presence and non-discoverable, then WebAuthn is completely stateless and deterministic for a given (challenge,rpId,origin) triplet
Being transparent looks cool, but doesn't it make it more attractive to opportunistic thieves? What about something more plain that just looks like a key fob?
I think it is a really smart concept. Take the measurement feature of a TPM but remove the untrusted components supplying the measurements.
I really want one. I just currently don't know how to write device driver stuff and my ADHD means if I don't accomplish a project instantly I won't accomplish it at all.
Or download for free the CryptoServer SDK from https://utimaco.com/products/platform/cryptoserver-general-p... Their SDK contains a HSM simulator. They provide instructions how to run it in a container so that you then even have a network HSM.
Ease into it. We have fairly good documentation and some getting started material you can read (tillitis.se, dev.tillitis.se, GitHub) to gauge your level of understanding. The design is also meant to have the bare minimum complexity necessary to accomplish its functionality. It seems to have potential as a learning platform for college students who want to understand computers from the gates and up.
I love how configurable this is and the ability to tamper with it
PS. Another question, any plans to adopt usb-a?