Unless I’m missing something, that sounds like it would be a firmware recompile away to spoof this using a sub-$20 teensy dev board. Am I missing something stronger than product id/vendor id/serial at play here? I think in many cases, grabbing the serial number to spoof would be relatively easy to automate by swapping someone’s charger out for a device that looks like a charger but also probes phones that are connected to it.
Its just an example, one could use phone or other USB device with lock app that would ask for simpler 4 digit PIN instead of full password for example. One could use USB with filesystem and execute a script that would look for a particular content in the file on that USB device … or even your private SSH key … its just a matter of choice.
You have to choose what is enough (and if its worth it) to unlock your laptop/workstation faster.
Lets assume that we will put our public SSH key (id_rsa.pub) on the USB drive.
Then, when we detect that this is the USB drive that we use to unlock, we mount it with filesystem that is available there, can be UFS on FreeBSD or ext4 on Linux for example, if it does not mount, then no unlock happens.
If it mounts, then make this command to compare our public SSH key (id_rsa.pub) against our private SSH key (id_rsa) available in home ~/.ssh directory.
Interesting idea but now you have only compared the keys. I can also copy those if I have access to the drive. So this only works with something like a dedicated thumb drive which you never plug in anywhere else.
You can generate new pair of keys for this purpose.
Besides … if someone already has the access to your drive and files then he does not need to ‘hack’ your phone or USB drive because he already has that access, or am I missing something? :)
What I mean is when you connect this drive to some other computer that computer can just copy the private key. You’re not really doing any crypto operation you just have a data file that needs to remain secret.
You can have encrypted file on the USB pendrive and a key to decrypt it on the laptop.
You can also have thousands of files and use just one - the least suspected one - to be used for unlock.
You can have encrypted file on that pendrive and a key to decrypt it on the laptop - but this does not change the general idea - if someone will get/copy that file and generate the same serial number for the pendrive then he will unlock your screen.
Its like with Yubi Key USB - if someone will get your Yubi Key he will be able to unlock things you lock with it - a general ‘physical’ security problem.
The thing about a Yubi Key is that if I plug it into a malicious computer, they can’t just copy it. It’s not a filesystem. The secrets it hold cannot be copied out of it. It’s a device that outputs something based on some input and you can cryptologically verify that the data has been through the Yubi Key.
Well, a) that’s not true. I can copy the entire drive and that will always work. So I can make a copy without the physical device being gone and b) a Yubikey is usually only a second factor it does not replace the password.
If this meets your security requirements that’s fine but I would not sign off on it. ;)
Well, at least with a YubiKey, there is not point torturing anyone anymore once they have given N fake pins (whatever you have set N to on your YubiKey).
Which actually sounds like a nice possible feature for YubiKeys: a special ‘poison pill’ PIN that you can give to immediately exhaust the counter. Then no one could ever decrypt the data.
Experimenting with onlykey that is an especially interesting feature it has. You can enter a PIN that just wipes it. I’m still kicking the tires and can’t issue any kind of general recommendation to use it. But I really like that feature for some reason even though it’s vanishingly unlikely that I’d ever need it.
It’s nice that it has that feature! However, I would be very worried by the security of OnlyKey. They do weird things like getting entropy from floating analog inputs, but due to some programming bug they actually use this entropy as a pointer to get the actual value, which ends up taking values from the vector table:
I saw that discussion. FWIW, on most similar devices, I prefer to generate my keys on a normal but offline system and import them ever since the primality testing SNAFUs in some evaluated modules about 15 years ago.
But I’m still looking at this as a fun development gadget so far. I have requested an unlocked device to explore in some more detail what could be done with it.
No, I did not tried that … but I have an idea how to implement that - by using MTP mount request on this phone’s storage. If you unlock the phone and then say AGREE to allow phone’s storage mounting then after successful MTP mount the computer can be unlocked.
I think if my options are between plugging in a cable and typing my password I would prefer the latter.
It would be nice if there was a PAM module for some of the phone authenticator apps, though.
It would also be interesting if this would work with position detection. Afaik none of the existing systems even prevent relay attacks but if it’s good enough for cars some people might consider it good enough for their computer.
The oath toolkit has such a module. I’ve only ever used it on a Linux server before, not on any kind of desktop and not on any kind of BSD. It looks like it’s been packaged for NetBSD at least though.
You’ll want to use TOTP for most of the authenticator apps.
I was thinking more along the lines of those apps asking you “is this you signing in”. Something with a simple Yes/No prompt. If the goal is to make something that is more convenient than a password…
I forgot about those and was just thinking of the OTP gadgets.
It would seem straightforward to modify a PAM module like that one such that it posts a request to an API that triggers a push notification, then when you say “that’s really me” has your phone post back the OTP for you. Might even be fun. That way the same scratch codes would work easily and everything…
Nice and practical approach. Though you probably want more than the device serial for this to be secure (depending on your threat assessment).
Compare with Apple Watch -> Mac proximity unlock:
When enabling an Apple Watch to unlock a Mac, a secure link using Auto Unlock Identities is established. The Mac creates a random one-time-use unlock secret and transmits it to the Apple Watch over the link. The secret is stored on Apple Watch and can only be accessed when Apple Watch is unlocked. The unlock token is not the user’s password.
During an unlock operation, the Mac uses BLE to create a connection to the Apple Watch. A secure link is then established between the two devices using the shared keys used when it was first enabled. The Mac and Apple Watch then use peer-to-peer Wi-Fi and a secure key derived from the secure link to determine the distance between the two devices. If the devices are within range, the secure link is then used to transfer the preshared secret to unlock the Mac. After successful unlock, the Mac replaces the current unlock secret with a new one-time use unlock secret and transmits the new unlock secret to the Apple Watch over the link.*
Sure. If I am target of the NSA or whatever, encryption does not matter. That does not mean that one should not use a cryptographically secure setup as a default. There are many other attack vectors that this protects very well against, including laptop theft, or being arrested by police that does not use wrenches to get a password (which is the most likely way to get arrested in my country).
Edit: not that I currently use this method for unlocking my Mac. I like Touch ID much more, but it was great before I had a Touch ID-capable Mac.
I really do not like the smart card ecosystem – probably because it will be a big PITA to setup such subsystem on FreeBSD to make it lock/unlock my laptop with a smart card – not to mention of it will be even possible because of probable lack of drivers for a laptop builtin smart card reader.
Get a gnuk token, which will definitely work on FreeBSD. You have a wide range of options, anything from a 30 Euro NitroKey Start to a $2 Blue Pill board from AliExpress. You can do some proper challenge-response authentication (e.g. let the key sign some randomly generated data). And even though gnuk tokens do not have a secure element, they are better protected against copying than a USB pen drive or phone serial number. And if the read protection bit is enabled, you cannot read the private key out of firmware using ST-Link.
As a bonus, you have a hardware key that you can use to sign/encrypt files, SSH auth, etc.
(I would strongly recommend a device with a secure element, but if YubiKeys are too expensive for your taste or you want the key to run open source software, gnuk is a good alternative.)
Another angle would be to use the secure element of your phone for authentication (somewhat similar to what Krypton does).
Unless I’m missing something, that sounds like it would be a firmware recompile away to spoof this using a sub-$20 teensy dev board. Am I missing something stronger than product id/vendor id/serial at play here? I think in many cases, grabbing the serial number to spoof would be relatively easy to automate by swapping someone’s charger out for a device that looks like a charger but also probes phones that are connected to it.
Its just an example, one could use phone or other USB device with lock app that would ask for simpler 4 digit PIN instead of full password for example. One could use USB with filesystem and execute a script that would look for a particular content in the file on that USB device … or even your private SSH key … its just a matter of choice.
You have to choose what is enough (and if its worth it) to unlock your laptop/workstation faster.
Right, but your suggestions will make it a lot more difficult to set up.
Not that difficult.
Lets assume that we will put our public SSH key (
id_rsa.pub) on the USB drive.Then, when we detect that this is the USB drive that we use to unlock, we mount it with filesystem that is available there, can be UFS on FreeBSD or ext4 on Linux for example, if it does not mount, then no unlock happens.
If it mounts, then make this command to compare our public SSH key (
id_rsa.pub) against our private SSH key (id_rsa) available in home~/.sshdirectory.If it matches, then unlock the screen.
Removal should be the same, after device removal just lock the screen.
Interesting idea but now you have only compared the keys. I can also copy those if I have access to the drive. So this only works with something like a dedicated thumb drive which you never plug in anywhere else.
You can generate new pair of keys for this purpose.
Besides … if someone already has the access to your drive and files then he does not need to ‘hack’ your phone or USB drive because he already has that access, or am I missing something? :)
What I mean is when you connect this drive to some other computer that computer can just copy the private key. You’re not really doing any crypto operation you just have a data file that needs to remain secret.
You can have encrypted file on the USB pendrive and a key to decrypt it on the laptop.
You can also have thousands of files and use just one - the least suspected one - to be used for unlock.
You can have encrypted file on that pendrive and a key to decrypt it on the laptop - but this does not change the general idea - if someone will get/copy that file and generate the same serial number for the pendrive then he will unlock your screen.
Its like with Yubi Key USB - if someone will get your Yubi Key he will be able to unlock things you lock with it - a general ‘physical’ security problem.
Hope that helps.
The thing about a Yubi Key is that if I plug it into a malicious computer, they can’t just copy it. It’s not a filesystem. The secrets it hold cannot be copied out of it. It’s a device that outputs something based on some input and you can cryptologically verify that the data has been through the Yubi Key.
Well, a) that’s not true. I can copy the entire drive and that will always work. So I can make a copy without the physical device being gone and b) a Yubikey is usually only a second factor it does not replace the password.
If this meets your security requirements that’s fine but I would not sign off on it. ;)
The ‘iswrong’ user just gave me a good idea - to copy one time keys to the USB pendrive for example.
I will think about it for a while :)
Ssh keys stored on a yubikey are pin-protected and the yubikey will reset itself after multiple failed attempts to unlock it.
No matter how good the encryption is, there is always this case where encryption quality does not matter at all :)
https://www.xkcd.com/538/
Well, at least with a YubiKey, there is not point torturing anyone anymore once they have given N fake pins (whatever you have set N to on your YubiKey).
Which actually sounds like a nice possible feature for YubiKeys: a special ‘poison pill’ PIN that you can give to immediately exhaust the counter. Then no one could ever decrypt the data.
Experimenting with onlykey that is an especially interesting feature it has. You can enter a PIN that just wipes it. I’m still kicking the tires and can’t issue any kind of general recommendation to use it. But I really like that feature for some reason even though it’s vanishingly unlikely that I’d ever need it.
It’s nice that it has that feature! However, I would be very worried by the security of OnlyKey. They do weird things like getting entropy from floating analog inputs, but due to some programming bug they actually use this entropy as a pointer to get the actual value, which ends up taking values from the vector table:
https://news.ycombinator.com/item?id=21889302
And their developers believing that passing dieharder is a good test for a hardware RNG for crypto:
https://news.ycombinator.com/item?id=21885109
The whole HN discussion is pretty cringeworthy.
I saw that discussion. FWIW, on most similar devices, I prefer to generate my keys on a normal but offline system and import them ever since the primality testing SNAFUs in some evaluated modules about 15 years ago.
But I’m still looking at this as a fun development gadget so far. I have requested an unlocked device to explore in some more detail what could be done with it.
I think I’d want to add some way to check that my phone was unlocked before letting it unlock my workstation. Did you try to do that at all?
No, I did not tried that … but I have an idea how to implement that - by using MTP mount request on this phone’s storage. If you unlock the phone and then say AGREE to allow phone’s storage mounting then after successful MTP mount the computer can be unlocked.
I think if my options are between plugging in a cable and typing my password I would prefer the latter.
It would be nice if there was a PAM module for some of the phone authenticator apps, though.
It would also be interesting if this would work with position detection. Afaik none of the existing systems even prevent relay attacks but if it’s good enough for cars some people might consider it good enough for their computer.
I did not disabled password authentication, I just added automatic screen unlock when I attach my phone so I still can login using just password.
The oath toolkit has such a module. I’ve only ever used it on a Linux server before, not on any kind of desktop and not on any kind of BSD. It looks like it’s been packaged for NetBSD at least though.
You’ll want to use TOTP for most of the authenticator apps.
I was thinking more along the lines of those apps asking you “is this you signing in”. Something with a simple Yes/No prompt. If the goal is to make something that is more convenient than a password…
I forgot about those and was just thinking of the OTP gadgets.
It would seem straightforward to modify a PAM module like that one such that it posts a request to an API that triggers a push notification, then when you say “that’s really me” has your phone post back the OTP for you. Might even be fun. That way the same scratch codes would work easily and everything…
I suspect they’re mostly USB devices supported by
pcscd/pcsc-lite/opensc/whatever-else-in-this-mess.Nice and practical approach. Though you probably want more than the device serial for this to be secure (depending on your threat assessment).
Compare with Apple Watch -> Mac proximity unlock:
https://support.apple.com/guide/security/apple-watch-usage-sec947c4b977/web
Good idea, to copy one time keys to the USB pendrive for example :)
You are missing the point that “The secret is stored on Apple Watch and can only be accessed when Apple Watch is unlocked.”
Indeed, an I bet that the secret can only be decrypted using the secure element, which can only be used by unlocking the watch.
No matter how good the encryption is, there is always this case where encryption quality does not matter at all :)
https://www.xkcd.com/538/
Sure. If I am target of the NSA or whatever, encryption does not matter. That does not mean that one should not use a cryptographically secure setup as a default. There are many other attack vectors that this protects very well against, including laptop theft, or being arrested by police that does not use wrenches to get a password (which is the most likely way to get arrested in my country).
Edit: not that I currently use this method for unlocking my Mac. I like Touch ID much more, but it was great before I had a Touch ID-capable Mac.
I really do not like the smart card ecosystem – probably because it will be a big PITA to setup such subsystem on FreeBSD to make it lock/unlock my laptop with a smart card – not to mention of it will be even possible because of probable lack of drivers for a laptop builtin smart card reader.
Get a gnuk token, which will definitely work on FreeBSD. You have a wide range of options, anything from a 30 Euro NitroKey Start to a $2 Blue Pill board from AliExpress. You can do some proper challenge-response authentication (e.g. let the key sign some randomly generated data). And even though gnuk tokens do not have a secure element, they are better protected against copying than a USB pen drive or phone serial number. And if the read protection bit is enabled, you cannot read the private key out of firmware using ST-Link.
As a bonus, you have a hardware key that you can use to sign/encrypt files, SSH auth, etc.
(I would strongly recommend a device with a secure element, but if YubiKeys are too expensive for your taste or you want the key to run open source software, gnuk is a good alternative.)
Another angle would be to use the secure element of your phone for authentication (somewhat similar to what Krypton does).