This is my first post so I don’t know if it’s in the right area, I was wondering if there was an implant that would allow me to login to my computer securely; I saw the post with the KBR1, but couldn’t the nfc implant just be cloned? And if so wouldn’t that different the point of it? I’m new to the RFID field; however, I do have a good understanding of electronics in general, just not this area. I also saw the DESFIRE and thought that might be a good choice but I haven’t seen anything that would allow me to login with it.
The KBR1 just acts as a keyboard which inputs whatever the implant emits. It is no different from typing in the password yourself except the password is stored in the chip. This is not encrypted because the KBR has no decryption mechanism with which to do so, so anything that it can read can be read by any other device which can read that chip.
The threats you will be facing would be either someone has physically restrained you and forces you to place your implant near a reader, or if they do it without you knowing. I would say that the chances of it happening without you knowing while you are conscious are extremely small, so what you would have to worry about is someone having access to you while you sleep, or someone physically restraining you.
For windows, your options are fairly limited without a full domain/kerberos. The options that don’t require this are similar to using the KBR1, IE just the uid.
Linux has support for u2f and fido2 as a PAM module. Most major distros have packages for it. The fido2 lib does have to be built with NFC support but again most distros have options.
Depending on your threat model, the UID would be enough.
My threat model is anyone who is not me, is unable to access the computer unless they want to cut off my hand or remove the implant, even with physical access to the computer. I’m tend to be overly cautious with my security online. Would the DESFIRE implants be best then? Assuming I could make a program or device(most likely) to work with it. If so which one would be best? I planned to get an apex flex for fido2 for online application as well.
It sounds like you would be well suited to what Tac0 suggested
They are very similar, with a couple of differences
Both are P71 Java Cards.
The Apex Flex is managed via the Fidesmo ecosystem for user-friendly app deployment. The flexSecure is a “naked” version using GlobalPlatform, for manual applet management.
Apex offers easier setup, while flexSecure provides full administrative control and a little more storage.
I have one of each
heres a little write up that may help you decide
Just note,
After sone amazing work by @GrimEcho and @StarGate01 there has been some awesome work by Tacos making the FlexSecure far less intimadating to get up and running, plus it comes with some “essential” apps preloaded (which you can remove if you want)
The closest you can come to this right now is Linux + full disk encryption via LUKS + FIDO2 support.
As @VenomRolls pointed out, it is relatively simple to get working, but it does require that you build libfido2 with an option to enable NFC support (it is relatively straightforward and I never had any issues building it) .
To support full disk encryption, you then need to add both your built libfido2 and pcsclite to the pre-boot environment (typically initramfs). There are tools that help you load modules into initramfs, but it does take some trial and error to get it working.
I got a prototype of this working with my Apex Flex, but I ended up not pursuing it because there isn’t a good way to set up a FIDO2 device as a second authentication factor. LUKS uses the concept of slots for storing encryption keys. An encrypted container or disk volume can be configured to support multiple slots, but each slot is expected to contain a encryption key, and by extension, only a single method for deriving it.
If you take an existing LUKS encrypted volume or container that is secured by a passphrase, then add your FIDO2 key to it, it will be configured as a 2nd slot. You will no longer need your phase phrase to derive the decryption key and unlock the computer, the FIDO2 device alone is sufficient.
In theory you can configure your FIDO2 device to require PIN authentication, but I was never able to get that flow working inside a pre-boot initramfs environment.
Using FIDO2 as an authentication mechanism is a little more secure than a KBR1 “dumb” reader, it it is still susceptible to replay attacks. If someone has access to your encrypted computer and makes a copy of the volume, then intercepts or captures the NFC traffic between your Apex and the reader (or between the reader and the machine), they will be able to replay that exact traffic to unlock the copy they made. They won’t be able to use the captured traffic on any other future copies (or any copies older than the last one), but there is nothing that can be done to prevent a limited replay attack other than detecting when a copy has been made.
This is a tighter variation of the Evil Maid attack.
I haven’t tried it, but I believe the Apex can act as a PKCS#11 card and the Clevis plugin to LUKS supports Shamir secret sharing, so you can require N-of-M inputs which can be any combination of PKCS#11, PIN/Password, TPM, network based (via Tang), or another layer of SSS.
I’m not sure that’s entirely accurate, when FIDO2 is used against a web service the server sends a unique challenge which the hardware token signs and returns. In this case the returned data is only valid for a single session because next time the unique challenge will differ.
When used for LUKS, the token operates in HMAC-secret mode and the input is a static value stored in the LUKS header. If you can intercept the reply from the token once, then you can use that to unlock the key slot forever. Even if you change the key slot (e.g. un-enroll the FIDO2 key) or if the attacker has an older version of the disk (even if it predates when you enrolled the FIDO2 token) they can use a copy of the LUKS header from when the FIDO2 key was valid to obtain the master ecryption key to access the older/newer copies. The only way to fully lock someone out after they have had access to the FIDO2 output and the LUKS header would be to run a reencrypt to change the master key.
