17.06
Technology
SuisseID and nPA Weaknesses
Eine deutsche Version des Inhaltes ist unter http://www.remote-exploit.org/?page_id=673 verfügbar.
Background
In September 2010 we were giving a talk on security concerns that come with SuisseID and the German electronic identity card (nPA). Since we didn’t want to torture the conference participants with boring talk no. 2000 on certificates and PKI, we decided not to focus on PKI but on applications and the environment (legal as well as technical aspects) of these smart card solutions.
First results
Just after we've ordered the certificates and had a first look at hard and software we thought, gosh… that does not look like what we were promised in first place. We decided to realise all scenarios of possible attacks as simple as possible and to therewith scratch only at the surface of the problem. We were aware of the fact that false information and marketing promises made in this case had to be confronted with harsh reality to start a critical discussion and to impose some “positive pressure“ on the producers.
1. class - Class-1 - What was it all about?
There are essential parallels between the German ePA (elektronischer Personalausweis, electronic identity card) – which is now called nPA, since the term ePA has already been worn out – and SuisseID. Both initiators of the products had for example decided to deliver the first generation with simple class 1 readers. The weak spots of these devices are well known and it should be common knowledge to every technical interested person that to enter a password on a computer is insecure. Any kinds of key loggers are part of every small-time criminal’s methods at hand to spread viruses and trojans; above all companies, which operate in the IT-security sector should be aware of these risks. Even more so does it seem inappropriate that these readers are still in use.
Resistant to learn
Official SuisseID sites as well as the SECO (Federal Department of Economic Affairs DEA) communicate as follows(Translated from German):
WTF, Really?
But there is even more to come. In an interview (http://www.anthrazit.org/index.php?apsid=653e0ad3&apid=951146169) with the Business Unit Manager Post SuisseID in Anthrazit Magazine could be read the following Statements (Translated from German):
What about security concerns?
Needs physical access to the chip card?? WTF???
Gentlemen, if you will pardon my saying so, but to put it straight, we decided to use a USB over network Software (a commercial shareware), which allows access to all USB devices over a local network. The bad hacker was supposed to take these over and abuse somebody else’s identity together with the beforehand sniffed PIN. We attached great importance to realising the scenario as simple as possible. The result can be seen in the video below.
| SuisseID / Smartcard USB Takeover from Max Moser on Vimeo. A proof of concept video, which demonstrates a successful attack on SuisseID with simplest means. More details can be found on http://www.remote-exploit.org. |
We used the popular Metasploit framework (best wishes to H.D. Moore and his co-workers), as well as some Meterpreter scripts, which upload and install the software (shown in the video). This was about it and the attack was over since the key logger is a component of Metasploit, however… So c’mon, 6-7 lines, that’s it. By the way, if you feel like supporting the open source project usbip.sourceforge.net or even come up with a more elegant solution, go for it. Remote access to USB devices is not new, but always nice to have.
Card reader fine, but what about the signatures?
We had even more concerns about the signature software SwissSigner and E-gov Local Signer we touched upon. SuisseID is basically supposed to provide a legally valid electronic signature. We were very surprised when we realised that both Java applications allow the signing of Javascript in pdf documents even though the code had not been interpreted or rendered. A pdf was written and signed in no time.
The signed original is available for download on http://www.remote-exploit.org/wp-content/uploads/2010/09/sigdemo.pdf Have a look at the effects by enabling or disabling Javascript in the settings of the Acrobat reader.
The document looks different depending on the software in use (SwissSigner, Egov Signer or Acrobat). But the sad thing is, that the signature stays intact under certain circumstances. This means that you can see the document has been modified, but the problem here is not the signature but the rendering. Exactly… Electronic magic ink! It’s very sad to hear that even SwissSign asserts that their product meets all legal requirements. http://swisssign.com/en/produkte/swiss-signer
 |  | ||
| Screenshots of a sales contract within the SwissSigner application. The picture shows a nice and sound motorcycle. | Here the same document shown in the Acrobat reader: The signed Javascript has been rendered, the document now shows a wreck instead of the nice motorcycle. Since the signed Javascript was rendered, the customer buys a wreck instead of the fantastic motorcycle. |
From our point of view, there is any kind of basic security measure missing that would prove the “immutability” of the document, since the documents look different depending on the software, even before the signature is applied. Soooo what??? We are not lawyers, but is this legal? And if we apply our concerns on the card reader, why do German nPAs not work with class 1 readers and here in Switzerland everything seems to be fine with these?
Legally unsolved questions (at least for us)
We posed some general questions:
We’d be pleased if Swiss institutions teaching law would deal with those questions, because we don’t know anything about it and do not want to spread false assumptions.
SSlides, links and stuff
More details and explanations can be found on the slides that came with our talk. We hope to have added some common sense to this discussion and helped to talk about the issues in a qualified way.
Press articles und information releases
To our favourite troll out there:
Oh, and to put it straight: The verification of the signature is only identical under certain circumstances. As mentioned in our talk, the verification of the signature can be repeated or displayed as "show signed version" in the Acrobat reader, which immediately shows you the real motorcycle. As described above, it is all about the difference in the rendering engine resp. if Javascript is rendered or not. But independently of the renderer, the signer should never ever sign dynamic data but convert them first into a static format, this is what we talk about here.
0 komentar:
Posting Komentar