Dormakaba uses a Key Derivation Function (KDF) to derive the keys for some of the Saflok MIFARE Classic sectors. This proprietary KDF only uses the card’s Unique IDentifier (UID) as an input.
Knowledge of the KDF allows an attacker to easily read and clone a Saflok MIFARE Classic card. However, the KDF by itself is not sufficient for an attacker to create arbitrary Saflok keycards.
Security is hard. Cryptography is even harder. Don’t roll your own algorithms, it’s just asking for a problem. And given that “oversight”, I’d bet that the rest of the kill chain involves equally bad encryption or hashing being used on the cards.
I’m curious, for a non-network connected lock, how could you ensure that it’s secured with time bound parameters like they list?
Now that I’m thinking about it I guess each lock would have a private key and a CMOS of sorts to keep time. The writer could then write have the public key of each room and that could have a timestamp as part of the encrypted payload. I guess to take it further you could reverse it too with that payload having a private key of the writer and the locks could verify the private key against a public key of the writer. At that point each writer would have to have the public key of all locks, and each lock would have the public key of each writer.
At that point your payload to encode would be a timestamp of expiration and any sort of “checksum” or PSK to verify it was made by a valid writer?
From the unsaflok.com site:
Security is hard. Cryptography is even harder. Don’t roll your own algorithms, it’s just asking for a problem. And given that “oversight”, I’d bet that the rest of the kill chain involves equally bad encryption or hashing being used on the cards.
I’m curious, for a non-network connected lock, how could you ensure that it’s secured with time bound parameters like they list?
Now that I’m thinking about it I guess each lock would have a private key and a CMOS of sorts to keep time. The writer could then write have the public key of each room and that could have a timestamp as part of the encrypted payload. I guess to take it further you could reverse it too with that payload having a private key of the writer and the locks could verify the private key against a public key of the writer. At that point each writer would have to have the public key of all locks, and each lock would have the public key of each writer.
At that point your payload to encode would be a timestamp of expiration and any sort of “checksum” or PSK to verify it was made by a valid writer?
Look up JSON Web Tokens, they work how this would need to work.