I don't see how this is an amateur mistake. Presumably the key material on the device needs to be available to its onboard computer. So, the computer needs to load it or work with it. You could encrypt it, sure, but with what key? Another key stored locally in plaintext?
Could you explain what alternative should be used in this case?
You can't decrypt information or validate a public key's signature with the hash of a private key. You need the actual private key unencrypted at some point; we solve this in most of our certs by encrypting them with a password that the user has to enter to decrypt, but access to the unencrypted private key is absolutely required at some point.
Thanks. Is it just a plaintext password? The exact mechanism wasn't obvious to me from the article, though I see the tech report has more detail. If authentication is based on storing a password on the key and sending it over the wire, then there's nothing to prevent capturing that and cloning a key. I guess that's the point. I agree that if the auth is a password challenge, then hashing it will prevent recovery of the key from the cylinder though.
Sounds like their lock is really just a "digital key", with wires sending bits that take the place of tumblers.
Could you explain what alternative should be used in this case?