Legal woes

Edit 2014-10-28

I received some comments and questions about the background, and here is a clarified tldr;

I implemented the same ciphers used by the IClass access control system so people can verify the already published security flaws in IClass installations.

A french company called INSIDE Securesent me a letter about this. I have previously never heard about them, but it appears they have been involved in the IClass technology.

You can read more about RFID access control systems and IClass security testing in my previous post.

Below is the original post.

I implemented the same ciphers used by the IClass access control system so people can verify the already published security flaws in IClass installations.

Last Friday, I received an email from INSIDE Secure, notifying me of (potential) intellectual property infringement.

Some background on this; an RFID-based access control system called IClass is used across the globe to provide physical access controls. This system, not unlike the even more common system Mifare, relies on cryptography to secure communications between a tag and a reader. In 2010, the first (afaik) paper was released which outlined several flaws in this system. Since then, several papers have been released which have thorougly dismantled the entire cryptographic workings of the IClass system.

Based on these papers, I implemented those ciphers and released the library. 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).

You can see the letter here, or in text below. I have redacted the names of the senders, as I do not wish to agitate anyone more than necessary.

To: Mr Martin Holst Swende <Address> Copy: Dr <Name omitted> - SVP and CTP, HID Global Meyreuil, on October 7 2014 Notification of Intellectual Prorietary rights Dear Mr Holst Swende, INSIDE Secure, licensor of technology to HID Global, is aware of content you provided on the webpages: https://github.com/holiman/loclass https://github.com/holiman/loclass/tree/master/loclass . Regarding the code contained in the library called loClass that you published at https://github.com/holiman/loclass/tree/master/loclass and the reference of the cipher method included in the paper "Dismantling IClass" published by Messrs Flavio D. Garcia, Gerhard de Koning Gans, Roel Verdult and Milosch Meriac at the end of 2011, please be informed that INSIDE Secure owns intellectual property rights covering the cipher method implemented by this code, in particular patents US 6,058,481, EP 0 890 157 and corresponding patents in China, Canada, and via EPO, France, United Kingdom and Germany. We informed Messrs Flavio D. Garcia, Gerhard de Koning Gans, Roel Verdult and Milosch Meriac of our rights on December 27th, 2011. They promptly indicated that they, "as a response to (your) request, (we) have decided to remove teh library iclass.tar.gz from the website http://openciphers.org. The file is no longer available." For you information, 35 United States Code 271 provides that whoever actively induces infringement of a patent shall be liable as an infringer. Consequently, a GNU license of this code should not be put at the disposal of third parties without a warning that the use of this code may infringe the rights of our company and expose them to an infringement action from us. More particularly, we request that you refrain from publishing the code. We therefore leav it up to you to decide whether it is wise to incite third parties to infringe our intellectual property rights. Feel free to contact us for more information about this topic. Thank you for you attention in this matter. Best regards, <XXX YYY> General Manager

Below is my response, sent at 2014-10-19.

Mr XXX and whom it may concern, Regarding the code published in the specified github-repository; https://github.com/holiman/loclass, I'd first like to put forth the following facts: * The code is an implementation of cryptographic algorithms described in the academic research paper "Dismantling IClass" and related papers*, published by the University of Nijmegen. * The code is written from scratch** and is based purely on the forementioned academic papers. That is, no reverse-engineering of proprietary software or hardware has been used before or during the writing of the code. * The code is intended for experimental and educational use and is not part of a commercial offering. * The code does not contain any previously unknown or unreleased finding regarding flaws in the cipher suite used by IClass. I am afraid I do not understand the reference to the file "iclass.tar.gz" and your communications with Garcia, de Koning Gans, Verdult and Meriac. I do not know what was contained within the file or the reasons why they decided to remove it. Regarding your request that I include a warning to users of the codebase; I have now included such a warning in each file of the codebase, and also added a warning shown during program execution. Please let me know if you want me to change anything in the text. Regarding intellectual property infringement, being a Swedish citizen, I am not an expert in US nor French laws on the matter. Of the cited patents, I was only able to locate one [1], with the following abstract: "A logic machine and a circuit for producing an authentication code for authenticating smart cards which include a cycle of steps wherein a bit word is read out of a secret memory with a plurality of bit words, and words read out during previous cycles are combined. The result of the combination is used as a generator word for generating the address of the word to be read out in the next cycle." Therein are eleven steps outlined which appears to primarily concern electrical engineering circuitry. In my (admittedly non-expert) view, these are hardly applicable on my published code _per se_. Thus, I have decided not to remove the published code from the repository. Finally, I want to stress again that everything contained in the repository is already publically known and available. Indeed, in order not to cause undue harm to HID Global/INSIDE Secure, I explicitly decided not to publish sensitive keys which is known to be exposed by several individuals but still unavailable to the general public. Regards, Martin Holst Swende [*] Aside from the "Dismantling IClass" - paper, other academic papers by the same authors have been used for correlation, for example "Wirelessly Lockpicking a Smart Card Reader" by Garcia, de Koning Gans and Verdult. [**] Also contains parts from PolarSSL DES-implementation (GPLv2). [1] http://www.google.com/patents/US6058481

Perhaps I am jaded from “internet security” scene, but I did not expect this.

In the world of “internet security”, where the sky is falling every other month, there is hardly much controversy any longer about full-disclosure email lists, exploitation frameworks and reverse engineering. Nowadays vendors, institutes and organizations offers bug bounties and competitions, and there is a high level of transparency regarding flaws and fixes, using a common rating system for vulnerabilities.

In “internet security”, all parties know that systems suffer from vulnerabilities, and if vendors are being forthcoming about vulnerabilities, users can take necessary steps to protect themselves from unnecessary risks. Controversy nowadays is generated by the sale of 0-days to private (and government) actors, since users are left as sitting ducks to those with enough money and resources.

In “internet security”, a vendor is given credit not for providing fail-safe invulnerable systems, but for responsible, accurate and timely security patches and advisories.

By contrast, the “physical security” scene appears about a decade behind, and I don’t believe this to benefit neither the customers, nor, in the long run, the vendors themselves.

I hope that this marks the end of the communications.

2014-10-20