Slashdot Mirror
Security Company Tries To Hide Flaws By Threatening Infringement Suit
An anonymous reader writes: An RFID-based access control system called IClass is used across the globe to provide physical access controls. This system relies on cryptography to secure communications between a tag and a reader. Since 2010, several academic papers have been released which expose the cryptographic insecurity of the IClass system. Based on these papers, Martin Holst Swende implemented the IClass ciphers in a software library, which he released under the GNU General Public License.
The library is useful to experiment with and determine the security level of an access control system (that you own or have explicit consent to study). However, last Friday, Swende received an email from INSIDE Secure, which notified him of (potential) intellectual property infringement, warning him off distributing the library under threat of "infringement action." Interestingly, it seems this is not the first time HID Global has exerted legal pressure to suppress information.
The library is useful to experiment with and determine the security level of an access control system (that you own or have explicit consent to study). However, last Friday, Swende received an email from INSIDE Secure, which notified him of (potential) intellectual property infringement, warning him off distributing the library under threat of "infringement action." Interestingly, it seems this is not the first time HID Global has exerted legal pressure to suppress information.
IClass, meet Barbara.
You can't handle the truth.
His implementation only uses non-secret memory and should therefor be safe from these patents. The patents described here rely on the contents of the memory of the contraptions to be "secret" to make the process "secure".
You could even say that the original implementation by INSIDE secure doesn't follow the patent since obviously, the memory content isn't that "secret" anymore.
I was promised a flying car. Where is my flying car?
It's seriously difficult to understand the mindset of the organization and how they came into this. Did they even bother hiring a competent cryptographer when designing their product ? Were they duped by someone they hired and led to design a insecure product ? Or is encrypting an RFID communication a difficult and non-trivial task with no known vetted solution ?
I don't think that the problem is difficult in some fundamental way (the problem of verifying a remote host with asymmetric crypto has been reasonably well explored with SSL/TLS, and an access control system has the advantage of being able to trust only a CA it controls, and the advantage that you need to get physical access to an RFID reader pad to attempt attacks); but there are significant practical challenges.
RFID chips are pretty power constrained, since they only get whatever energy they can scavenge from the reader's RF output; and customers want them to be cheap. The industry also has fairly long product lifecycles (since, once you've put in a zillion card readers and integrated it with all your other building security stuff you don't want to rip it out and upgrade in 2 years).
It isn't so much a 'there is no known cryptographic solution to this problem' issue as a 'Why yes, we still have major customers using the 'security' provided by the lousy proprietary cryptosystem that our engineers were able to cram into a cheap, power-constrained, chip using the fab processes available in the mid to late 90s, and we really don't want to fix that' issue.
Beer should be served at room temperature (not warm). If it needs to be chilled, which reduces the sensitivity of the tastebuds, then the correct solution is to buy better beer.
I am TheRaven on Soylent News