Anchor: Hardware-based authentication using SanDisk USB devices
8 comments
To call this "security" is funny in my opinion, can't any application also fetch the serial number?
And also do they not get saved in logs like dmesg?
And also do they not get saved in logs like dmesg?
You could also use encrypted and signed keys on the devices to confirm that it's the correct drive.
Was recently watching a video on the RFID tags that Bambu Labs use on their spools and not only is the tag data encrypted, it's signed so even if you bypass the encryption, you still don't have a way to spoof the signature.
Was recently watching a video on the RFID tags that Bambu Labs use on their spools and not only is the tag data encrypted, it's signed so even if you bypass the encryption, you still don't have a way to spoof the signature.
If they're just files on a flash drive, what stops someone from just copying the files to another drive? Its just moving the same issue up a level in the stack, and in many ways making it easier to clone it.
One of the whole points of authenticator devices is that the actual key material isn't directly readable. You shouldn't be able to trivially reproduce the device.
One of the whole points of authenticator devices is that the actual key material isn't directly readable. You shouldn't be able to trivially reproduce the device.
If you can restrict the software, this would be a good way for controlling physical user ‚presence‘ - like in the supermarket, when a supervisor needs to scan their card for a cash register to take out a wrongly scanned item. I like it!
Calling this "hardware-based security" is somewhere between disingenuous and dangerously naive. Hardware-based security normally implies hardware with a dedicated secure element with cryptographic identities which are impossible to spoof. Security based on USB serial numbers can be defeated by any adversarial device claiming to use the same serial device as a device you have registered. There's no secure signatures or anything backing a USB serial number.
This is so, so much worse than that though, because the code doesn't even do what the AI-hallucinated documentation describes, because as far as I can tell the actual "serial number" is returned by the following line: Ok(Some(format!("{:?}", device.product_id()))) So the "serial number" is actually the USB product id, which generally corresponds to the "model", not even unique per-device. So you didn't even test this with multiple identical flash drives.
This is so, so much worse than that though, because the code doesn't even do what the AI-hallucinated documentation describes, because as far as I can tell the actual "serial number" is returned by the following line: Ok(Some(format!("{:?}", device.product_id()))) So the "serial number" is actually the USB product id, which generally corresponds to the "model", not even unique per-device. So you didn't even test this with multiple identical flash drives.
How else would you recover from a device failure?
You enroll up another hardware device (or 2) as a backup and securely store them in different places.
This is normal to do for yubikeys, for example.
The main point is that the secrets stored on the device are usually used to unlock other secrets stored elsewhere, and so themselves don't need to be synchronized often.
This is normal to do for yubikeys, for example.
The main point is that the secrets stored on the device are usually used to unlock other secrets stored elsewhere, and so themselves don't need to be synchronized often.
You don't.
The normal procedure here is to have multiple unique keys with multiple unique secrets. If one breaks that's it it's broken. This also allows you to revoke a key without removing all keys.
Github:https://github.com/TheEleventhAvatar/Anchor