this post was submitted on 21 Mar 2024
97 points (97.1% liked)

Technology

34858 readers
137 users here now

This is the official technology community of Lemmy.ml for all news related to creation and use of technology, and to facilitate civil, meaningful discussion around it.


Ask in DM before posting product reviews or ads. All such posts otherwise are subject to removal.


Rules:

1: All Lemmy rules apply

2: Do not post low effort posts

3: NEVER post naziped*gore stuff

4: Always post article URLs or their archived version URLs as sources, NOT screenshots. Help the blind users.

5: personal rants of Big Tech CEOs like Elon Musk are unwelcome (does not include posts about their companies affecting wide range of people)

6: no advertisement posts unless verified as legitimate and non-exploitative/non-consumerist

7: crypto related posts, unless essential, are disallowed

founded 5 years ago
MODERATORS
top 8 comments
sorted by: hot top controversial new old
[–] sylver_dragon@lemmy.world 17 points 7 months ago (1 children)

From the unsaflok.com site:

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.

[–] ramble81@lemm.ee 1 points 7 months ago (1 children)

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?

[–] August27th@lemmy.ca 1 points 7 months ago

Look up JSON Web Tokens, they work how this would need to work.

[–] zeusbottom@sh.itjust.works 12 points 7 months ago* (last edited 7 months ago) (1 children)

In 2011 I was aghast when I learned a popular keycard / biometric system used FTP to pull down its cleartext list of acceptable keys from the server.

The username was something like ADMIN and the password was PASS.

And no, that wasn’t the FTP command; that was the password.

So I’m not surprised that there are still problems with these devices.

edit: more complete thought

[–] NOPper@lemmy.world 5 points 7 months ago

To be fair to manufacturers for once here, this kind of this is usually due to users not properly securing these systems. The industry is still way behind on proper infosec but they've come a long way the last 10 years or so.

[–] don@lemm.ee 8 points 7 months ago

Corporate shareholders: is it cheap? Yes? Do I ever stay there? No? tfw I don’t give a fuck lol

[–] 7heo@lemmy.ml 7 points 7 months ago
[–] BuryMyHorse@lemmy.world 1 points 7 months ago

Sick! Would a Chameleon Ultra also work?