
Introducing the Librem Key - abrowne
https://puri.sm/posts/introducing-the-librem-key/
======
schoen
> The Librem Key opens up possibilities for even stronger anti-interdiction
> protection for customers who need it. We will be able to link a Librem Key
> with a laptop running Heads at our facility and then ship them separately.
> Then when each package arrives you can immediately test for tampering with
> an easy “green is good, red is bad” test.

That's really neat, but I'm curious about what interdiction threat models this
does or doesn't help with. For example, could the people performing the
interdiction have sophisticated enough hardware-tampering capabilities that
they could modify the key or extract its secrets and then send it on its way?
Could they have a small enough chip that they could place in the USB connector
itself to do some kind of malicious thing later on?

~~~
TheSpiceIsLife
I've always assumed if you are a high-value target and a state-level actor, or
a sufficiently motivated private entity, knows where high value hardware is
being manufactured, or dispatched from, you ought to assume your security is
already hosed. Either because they've simply tracked the delivery or tampered
with it.

Are we to assume the CIA and it's ilk don't have operatives inside these
organisations?

Of course, if you're sufficiently organised, you'd have low level grunts take
on all the risk.

Or did staying up for way too long selling meth-amphetamine for the better
part of a decade make me _way too paranoid_?

------
bcaa7f3a8bbc
Looks like... It's just a Nitrokey Pro with different branding, nothing
special. But this is how open hardware designs should work, and having
multiple vendors is good.

 _edit: the hardware design is nearly identical, but not the firmware. See my
follow-up post._

~~~
simcop2387
Looks like hardware wise that's true, but from the article they've added what
looks like a challenge response type mode that the key informs you about
(based off totp?) so that you can say that the bios has validated itself to
the key.

    
    
        We have worked with Nitrokey to add a custom feature to
        our Librem Key firmware specifically for Heads. This 
        custom firmware along with a userspace application allows
        us to store the shared secret from the TPM on the Librem
        Key instead of on a phone app. Then when Heads boots, if
        the BIOS hasn’t been tampered with the TPM will unlock
        its copy of the shared secret, and Heads will send the
        6-digit code over to the Librem Key. If the code matches
        what the Librem Key itself generated, it flashes a green
        light. If the codes don’t match, it flashes a red light.
    

I can't say I know how secure or safe this is going to be without examining it
in detail myself (and even then i'm an amateur at cryptography stuff) but it
sounds like a good start to things.

~~~
bcaa7f3a8bbc
> _I can 't say I know how secure or safe this is going to be without
> examining it in detail myself_

I've been working on something about Heads (a minimal Linux-based secure
bootloader) since January, too. And I can say the boot verification used by
Heads is sound and solid. The implementation is basically a verified/measured
boot scheme with TOTP.

During initialization, you generate a random TOTP key, add the key to your
TOTP authentication device (e.g. Google Authenticator on mobile phone), and
"seal" the key in your TPM, along with your boot "measurements". During the
boot process, these "measurements", or the SHA hashes of various
information/configuration about hardware, software and firmware, is being
passed to the TPM. If the configuration has changed, the TPM will refuse to
release the TOTP secret, otherwise, the TOTP key is released, then used to
calculate a random number by a shell script in Heads.

If the number on your mobile phone matches with the number on the screen, then
it proves the system is not being tampered.

Read the code here:

[https://github.com/osresearch/heads/blob/584c07042ef4898de52...](https://github.com/osresearch/heads/blob/584c07042ef4898de52ba4981997211c646b75fd/initrd/bin/gui-
init#L93)

[https://github.com/osresearch/heads/blob/584c07042ef4898de52...](https://github.com/osresearch/heads/blob/584c07042ef4898de52ba4981997211c646b75fd/initrd/bin/unseal-
totp)

(yes, all shell scripts... I'm not sure whether this is a security issue, but
this design is probably inspired by the initrd/sysvinit shell scripts)

Obviously, it means every time you boot your computer, it requires you to
check the 6-digit code against your phone, before it boots the actual Linux
kernel, or enter your full-disk encryption key. To me, Librem Key improves it,
by automating the process (as Nitrokey has TOTP functionality already), and
using a simple protocol to automate the challenge-response verification.

If you want to learn more, make sure to read about Heads first.

[https://github.com/osresearch/heads](https://github.com/osresearch/heads)

This presentation is a good start.

[https://trmm.net/Heads_33c3](https://trmm.net/Heads_33c3)

Attack Vectors:

1\. The trustworthiness and security of the TPM. The Free Software community
has historically rejected them because of the DRM aspect of "trusted"
computing. But to this day, the complete DRM dystopia (where all the
proprietary software is running inside Intel Management Engine, and performs
DRM-related cryptography in TPM blackboxes, was it called Microsoft
Palladium?) didn't turn out to be a threat, fortunately. So now even RMS
acknowledged that there is no actual reason to not implementing free software
security tools based on TPM.

Another reason is potential backdoor, but even there is a backdoor, using it
still improves security, compared to completely unprotected machines. In the
future, perhaps there can be Free Hardware TPM, but not in the foreseeable
future, and Heads's usage of TPM is still a big step towards security.

2\. Completeness of measurements. If some software/hardware changes are not
measured, or can be replayed by the attacker, the attack will not be detected.
But the measurements are done collaterally by coreboot in early boot, and
Heads in later boot, and to me is fairly extensive. Maybe there is still room
for attacks, but difficult. Pentesters are always welcomed. BTW, man-in-the-
middle attack to the entire verification process is possible, but it only has
theoretical interests, as the attacker has to stay in the middle between you
and your screen.

3\. Another general issue is the security of the TOTP seed, like, if your
Google Authenticator is hacked. The problem is somehow mitigated by using a
Nitrokey/Librem Key, but the TOTP code is still running on a generic STM32F1
MCU, not the OpenPGP Card. STM32F1 is known for its tamper-nonresistance. But
because of NDAs, there is currently no good alternative choices though. But
still, just like TPM, I think it greatly improves the current situation so
far, let's use it. It still has problems, and in the future we may do better.

4\. Automation. Librem Key automates the challenge-response, unlike the
original Heads, which prints the code on the screen. In the original Heads, if
Heads itself is tampered, it will noticed by the user for incorrect/no code.
But with automation, perhaps the attacker has a way to trick the users now?
Need to check this.

> _and even then i 'm an amateur at cryptography stuff_

Me too. I'm also working on a similar security token in my spare time.
Hopefully, before the New Year, I can submit a Show HN. You may find it's
interesting to read.

Finally, all of my descriptions are based on my first-hand impressions, not
necessarily facts, and totally unverified. Make sure to check the primary
sources!

~~~
Animats
_But to this day, the complete DRM dystopia (where all the proprietary
software is running inside Intel Management Engine, and performs DRM-related
cryptography in TPM blackboxes, was it called Microsoft Palladium?) didn 't
turn out to be a threat, fortunately._

That's optimistic. It's reasonable to assume that Intel's Management Engine
has been penetrated by NSA, the CIA, the FSB, and the PLA's Third Department.
It mostly relies on security through obscurity, which can be overcome with
money.

~~~
bcaa7f3a8bbc
Your point is about mass surveillance and the inauditable backdoor of ME,
which is an important security issue by its own, and I'm definitely not
optimistic about the situation, especially when Boot Guard rendered removal
impossible.

What I was addressing there is a different issue, which was how the general
objection of TPM in FOSS community came from - In the original vision of
"Trusted Computing" around 2006, it was expected that a TPM and ME-based DRM
would prevail in a proprietary system and lock every piece of media, software,
and file down.

You can read Lucky Green's presentation from 2002 to understand more about the
situation of that time.
[https://web.archive.org/web/20180416211840/https://cypherpun...](https://web.archive.org/web/20180416211840/https://cypherpunks.to/TCPA_DEFCON_10.pdf)

> _You could create Word documents that could be read only in the next week_

\- Steven Levy

> _Fritz Hollings Bill: S. 2048_ : _Plug “analog hole” with 2048-bit RSA_ :
> _Monitor out, Video out, Audio out._ _Microsoft:_ _Additionally encrypt
> keyboard input to PC._ _S. 2048 makes it illegal to sell non-TCPA compliant
> computers_ : _A $500,000 fine and 5 years in prison for the first offense;
> double that for each subsequent offense._

But fortunately, THEY were way too optimistic...

> _As of 2015, treacherous computing has been implemented for PCs in the form
> of the “Trusted Platform Module”; however, for practical reasons, the TPM
> has proved a total failure for the goal of providing a platform for remote
> attestation to verify Digital Restrictions Management. Thus, companies
> implement DRM using other methods. At present, “Trusted Platform Modules”
> are not being used for DRM at all, and there are reasons to think that it
> will not be feasible to use them for DRM. Ironically, this means that the
> only current uses of the “Trusted Platform Modules” are the innocent
> secondary uses—for instance, to verify that no one has surreptitiously
> changed the system in a computer._

> _Therefore, we conclude that the “Trusted Platform Modules” available for
> PCs are not dangerous, and there is no reason not to include one in a
> computer or support it in system software._

[https://www.gnu.org/philosophy/can-you-
trust.en.html](https://www.gnu.org/philosophy/can-you-trust.en.html)

------
tptacek
The Nitrokey Pro this is based on doesn't do U2F, according to Nitrokey's
literature and reviews of the product. Does this custom firmware somehow add a
U2F capability?

If it doesn't, I don't understand the product. It's more expensive than a
Yubikey 4, and bigger, and the Y4 does U2F along with the smard card RSA
stuff.

We use Y4s in our practice, and my experience is that for every time I use the
smart card RSA stuff (for instance, to SSH into something with a long-term RSA
key), I use the U2F feature 10 times.

~~~
Leace
> ... Y4 does U2F along with the smard card RSA stuff.

PIV applet also supports P-256:
[https://developers.yubico.com/PIV/Introduction/YubiKey_and_P...](https://developers.yubico.com/PIV/Introduction/YubiKey_and_PIV.html)

> ... for every time I use the smart card RSA stuff (for instance, to SSH into
> something with a long-term RSA key), I use the U2F feature 10 times.

Does that mean you use SSH rarely, login to U2F sites frequently or use
different keys for SSH (e.g. not on Yubikey)?

~~~
pvg
[https://news.ycombinator.com/item?id=17682946](https://news.ycombinator.com/item?id=17682946)

The thread is actually better than the linked post because it tells you about
ways you can (relatively easily) set up systems without long-term ssh keys.

~~~
tptacek
Right, there's an interesting split in modernizing/hardening SSH philosophies:

Philosophy 1: Move to hardware SSH keys. That's what Y4s and Nitrokeys
represent: keys where, if your machine is compromised, the SSH key itself
can't easily be stolen.

Philosophy 2: Move to SSH CAs that issue short-lived certificates, and use U2F
to authenticate issuance. This is roughly how you'd do a modern integration of
an SSO system (like Okta or GSuite) with your SSH services.

SSH CAs have more steam behind them, and are desirable for a bunch of reasons
that hardware SSH keys don't really address.

Since the primary function (beyond U2F, which these keys don't do) of a
hardware key is to protect your SSH key, I guess it's worth considering how
they fit into the modern SSH worldview or whatever you want to call it.

~~~
nickik
I like non of these optins. What I want is U2F for every ssh connection.

~~~
zimbatm
HashiCorp Vault also supports that scenario:
[https://github.com/hashicorp/vault-ssh-
helper](https://github.com/hashicorp/vault-ssh-helper) . The main downside is
that if the Vault instance is down, nothing can be SSHed into.

------
jaytaylor
Sad that the form factor looks terrible compared to YubiKey Nano.

It'd be really cool to have a similarly priced "open" solution which comes in
a minimally invasive package.

For reference: [https://i1.wp.com/vaultumllc.com/wp-
content/uploads/2017/03/...](https://i1.wp.com/vaultumllc.com/wp-
content/uploads/2017/03/YubiKey-4-Nano-In-Use-1.png?fit=1200%2C800&ssl=1)

~~~
daveFNbuck
The YubiKey Nano is meant to be left constantly in the USB drive, essentially
turning your entire laptop into a key. That doesn't work if the key is meant
to be used to unlock the laptop.

------
henkdevries
I love the Nitrokey products and recommend everyone to try them out. The
Nitrokey Start is a fully open source GnuPG token just in software (gnuk).
Their pro and hsm rely on a smartcard, of which the code is not fully open
(based on Smartcard-HSM for the Nitro key HSM).

------
GNOMES
How SOL are you if you lose one of these? With 2factor QR codes, you can save
the picture as a "backup" or generate backup codes through the service.

I haven't carried a thumb drive in a while, but I personally have lost a
couple before...

~~~
tptacek
You generally do one (or both) of two things with hardware security devices:

* You buy multiple devices and configure your systems to honor both, as a backup plan.

* You back up your keys or their artifacts to paper or a small drive and keep that somewhere safe.

If you do neither of those things, and you lose the hardware key, you are
either (a) boned or (b) using an insecure system where the key is just
theater.

~~~
mikepurvis
Isn't the point of this device that it generates the private key onboard and
never divulges it? Or does it have a one-way lever you have to pull at the
beginning before which it's possible to sync the key to another device or
download and print it?

~~~
tptacek
You can literally export the RSA key from some of these keys (for backup
purposes), but you can also just enroll multiple keys in whatever system
you're using them with (or, you can enroll a software-based key, which you
then keep only on a disconnected storage device).

------
rthille
I'm surprised there's no button. No way for the user to show intent (for
whatever action: signing, decryption, etc).

------
y0ghur7_xxx
What are these keys used for? Is it for 2FA? I would love to use my phone for
2FA, and not have to carry an usb device with me, because

\- I often log in to web services on my phone, and I don't have an usb adapter
cable with me to use the key, and

\- because having to carry a device always with me sounds cumbersome. My phone
is always with me anyways.

Is there some other use case I am overlooking? I am eagerly awaiting browser
vendors to implement these use cases: [https://w3c.github.io/webauthn/#use-
cases](https://w3c.github.io/webauthn/#use-cases)

~~~
cal5k
TOTP/HOTP can still be sort of trivially MITM'd - a phishing form could ask
for your auth code and then turn around and supply it to the site in question.

U2F uses a challenge-response protocol that should (in theory) make it
impossible to MITM. Google has said that they have had zero successful
phishing attacks since they switched to using U2F devices (I think Yubikeys)
for all employees.

------
kxyvr
Some of the other posts have already picked up that this doesn't appear to do
U2F. Along that line, does anyone know if there are any new FIDO2 compliant
keys are the market is is still just Yubikey? Are more sites adopting Webauthn
or is it stagnant?

~~~
TD-Linux
Nitrokey, the manufacturer of the Librem Key, has a U2F key available for
preorder.

~~~
bubblethink
That's a third party product. Nitrokey doesn't have u2f in any of their
products yet.

~~~
jans23
The Nitrokey FIDO U2F is compliant to Web Authentication (WebAuthn) but it's
not FIDO2. The main difference is that FIDO2 promises to replace passwords
while FIDO U2F is supposed to be a 2nd factor (in addition to a password).
Nitrokey FIDO U2F is not a third party product but it's source is available
here: [https://github.com/Nitrokey/nitrokey-
fido-u2f-firmware](https://github.com/Nitrokey/nitrokey-fido-u2f-firmware)
[https://github.com/Nitrokey/nitrokey-
fido-u2f-hardware](https://github.com/Nitrokey/nitrokey-fido-u2f-hardware)

~~~
bubblethink
I was going by the announcement on this page
[https://www.nitrokey.com/news/2015/5-new-nitrokey-models-
and...](https://www.nitrokey.com/news/2015/5-new-nitrokey-models-and-their-
availability) which states, "The Nitrokey U2F is a third party product ..." as
well as some historical articles like this one
[https://lwn.net/Articles/695438/](https://lwn.net/Articles/695438/). I wasn't
aware that this was an official product developed by nitrokey. Did this change
recently ?

------
agrinman
Does this device support U2F?

~~~
tptacek
Nitrokeys generally do.

~~~
bubblethink
The nitrokey u2f is a third party product. I don't think any of their products
support u2f yet.

~~~
jans23
The Nitrokey FIDO U2F is not a third party product but it's source is
available here: [https://github.com/Nitrokey/nitrokey-
fido-u2f-firmware](https://github.com/Nitrokey/nitrokey-fido-u2f-firmware)
[https://github.com/Nitrokey/nitrokey-
fido-u2f-hardware](https://github.com/Nitrokey/nitrokey-fido-u2f-hardware)

------
nickik
Wow, the integration with the heads bios is something I thought for a long
time would be a great feature for a external key.

The problem is just that we don't live in a world where most people can use
heads.

You either have to buy older hardware that is compatible with coreboot or buy
a Librem laptop.

------
mitchtbaum
Alternatively, you could keep a microsd card in a ring to safely store key
files.

[https://www.thingiverse.com/thing:1970583](https://www.thingiverse.com/thing:1970583)

------
badtuple
Don't know how possible this is to answer, but how likely is it that a device
like this would fail?

~~~
daxorid
I don't know about specific MTBF rates, but all hardware eventually goes bad
or gets damaged. The standard protection against failure ( and loss, and theft
) is to register multiple devices with your accounts and physically secure the
backups.

