full-disclosure - Atmel "secure" crypto co-processor series microprocessors (AT91SAM7XC) leaking keys, plus bonus DESFire hack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <5118B5DF.2020700@algroup.co.uk>
Date: Mon, 11 Feb 2013 09:11:59 +0000
From: Adam Laurie <adam@...roup.co.uk>
To: bugtraq@...urityfocus.com, full-disclosure@...ts.grok.org.uk, 
	Adam Laurie <adam@...roup.co.uk>
Subject: Atmel "secure" crypto co-processor series
 microprocessors (AT91SAM7XC) leaking keys, plus bonus DESFire hack

The Atmel AT91SAM7XC series of microprocessors contain a crypto 
co-processor which is DES and AES capable. They include a write-only 
memory for key storage and multiple physical security measures to 
prevent decapping etc.

However, due to poor memory management, in certain circumstances it is 
possible to recover the crypto keys from a live system via the standard 
JTAG programming interface. These circumstances are made more likely to 
exist in the wild by the fact that the example software provided by 
Atmel is itself vulnerable.

Full story here:

http://oamajormal.blogspot.co.uk/2013/02/atmel-sam7xc-crypto-co-processor-key.html

The potential for this to be an issue has been raised within the Atmel 
support community several times over the years, dating back to at least 
2006. I personally raised it with them in 2011.

However, I am not aware of any clarification being issued by Atmel, nor 
of any definitive proof one way or the other being made public until now.

The NXP DESFire 'hack' is purely a result of the weakness in the 
AT91SAM7XC, and nothing to do with DESFire itself, but demonstrates why 
this is a real problem. I'm sorry they got in the firing line, but they 
were just in the wrong place at the wrong time... (cyber)war is heck!

cheers,
Adam
-- 
Adam Laurie                         Tel: +44 (0) 20 7993 2690
Suite 117                           Fax: +44 (0) 20 7691 7776
61 Victoria Road
Surbiton
Surrey                              mailto:adam@...roup.co.uk
KT6 4JX                             http://rfidiot.org

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/