|
|
|
|
|
|
by Spooky23
176 days ago
|
|
|
It’s minor but can improve user experience if implemented well. I know several people who scoffed at the “need” for automation in car locking and unlocking. It just feels like the obvious way now. Another use case would be access control in buildings. There are millions of insecure iClass type cards securing doors and elevators that would be easily and securely replaced by tech like this. Another scenario is getting census/surveillance capability for security and evacuation. Another is emergency response. If the tech was in a phone, integrate with 911 to find where a cell call originated within a campus or facility. I worked a project in an office complex where we worked with the fire department to improve response time. The Fire Department response was 5 minutes, but locating a caller in our facility could take 7-10 without a guide. In some cardiac scenarios, every minute without treatment reduces survival probability by 10%. You can easily cut that time by 50-75% if you know exactly where you are going. In the case of that project, we deployed AED devices, created and drilled procedures for reporting emergencies (with a bias for using house or desk phones) we also required a buddy system for most after hours access. I think it lowered the average drilled response by 30-40%. That paid off when a vendor CE had a heart attack during a service event. Without that system, he would have almost certainly died. Very few companies have that kind of safety culture and budget so tech can have a huge impact. |
|
|
Those cards could be replaced, even more easily, with NFC cards with better security properties. ISO 14443-3A is a perfectly adequate protocol and has the nifty added benefit of not needing batteries in the card.
Even secure ranging is doable at NFC frequencies — all it takes is a vendor who is willing to do the work as well as customers who will demand it. I think I even saw papers about this years ago: the reader and the card can securely negotiate a request that the door will send and the card will reply to, and then the door sends the request and the card validates the request (against precomputed data) and replies. It’s okay if there’s delay due to the limited computational power of the card as long as the card knows what the delay is and can report the delay to the reader. This will give ranging precise to a bit time or better, which is nowhere near the 10cm precision that UWB offers but is a whole lot better than anything anyone has actually deployed in an iClass-style device.
But customers aren’t even demanding cards that are immune to trivial UID cloning.