Hard to clone Micros.

Unbeliever wrote:

>I need a hard to clone Micro.  I'd appreciate any input from the illuminati
>that inhabit this corner of cyberspace.  I am aware that PICs with the
>security fuses blown are very easy to clone using invasive techniques.  I
>have seen websites that offer to "recover lost code" from AVRs, Philips
>8051's and others.
>
>Do any of you guys have any experience in what's easy and what's hard to
>read and/or clone in the current range of reasonably priced (sub US$10)
>micros?
>
>--
>Alf Katz
>alfkatz@remove.the.obvious.ieee.org

I know of no example of anyone ever defeating the security 
of a Dallas/Maxim DS5240/DS5250 microcontroller.  Perhaps a
government agency can, but it has proved to be secure in
banking applications.

http://www.maxim-ic.com/appnotes.cfm/appnote_number/2033
http://pdfserv.maxim-ic.com/en/an/AN2033.pdf
http://www.maxim-ic.com/DS5240
http://pdfserv.maxim-ic.com/en/ds/DS5240.pdf
http://www.maxim-ic.com/DS5250
http://pdfserv.maxim-ic.com/en/ds/DS5250-DS5250F.pdf
http://www.maxim-ic.com/products/microcontrollers/information.cfm
http://www.maxim-ic.com/appnotes.cfm/appnote_number/3294
http://www.rentron.com/Files/Dallas/secure.pdf (large)

If you are bound by export restrictions, the Dallas/Maxim 
DS5002 may be an acceptable (but less secure) alternative.
http://pdfserv.maxim-ic.com/en/ds/DS5002FP.pdf
http://www.maxim-ic.com/appnotes.cfm/appnote_number/2034

Atmel also has some chips that they claim to be secure, 
but I have not evaluated them in detail.
http://www.atmel.com/products/SecureM68HC05/
http://www.atmel.com/products/SecureAVR/Default.asp
http://www.atmel.com/products/SecureARM/Default.asp

(I had some trouble finding pricing on the Dallas chips; 
if you get pricing, please post the information here.)


-- 
(misc.business.product-dev welcomes crossposts from comp.arch.embedded.
comp.arch.embedded users get whitelisted when they first crosspost to
misc.business.product-dev so that they will not experience any delays.)

Guy Macon schrieb:
> 
> If you are bound by export restrictions, the Dallas/Maxim 
> DS5002 may be an acceptable (but less secure) alternative.
> http://pdfserv.maxim-ic.com/en/ds/DS5002FP.pdf
> http://www.maxim-ic.com/appnotes.cfm/appnote_number/2034
> 
Hello,

Markus Kuhn has shown 1996 that the DS5002 is not very secure:
http://www.cl.cam.ac.uk/~mgk25/kuhn-da.pdf
http://www.cl.cam.ac.uk/Research/Security/studies/st-rs.html

Bye

Uwe Hercksen wrote:
>
>Guy Macon <http://www.guymacon.com/> schrieb:
>> 
>>I know of no example of anyone ever defeating the security 
>>of a Dallas/Maxim DS5240/DS5250 microcontroller.  Perhaps a
>>government agency can, but it has proved to be secure in
>>banking applications.
>>
>>http://www.maxim-ic.com/appnotes.cfm/appnote_number/2033
>>http://pdfserv.maxim-ic.com/en/an/AN2033.pdf
>>http://www.maxim-ic.com/DS5240
>>http://pdfserv.maxim-ic.com/en/ds/DS5240.pdf
>>http://www.maxim-ic.com/DS5250
>>http://pdfserv.maxim-ic.com/en/ds/DS5250-DS5250F.pdf
>>http://www.maxim-ic.com/products/microcontrollers/information.cfm
>>http://www.maxim-ic.com/appnotes.cfm/appnote_number/3294
>>http://www.rentron.com/Files/Dallas/secure.pdf (large)
>>
>>If you are bound by export restrictions, the Dallas/Maxim 
>>DS5002 may be an acceptable (but less secure) alternative.
>>http://pdfserv.maxim-ic.com/en/ds/DS5002FP.pdf
>>http://www.maxim-ic.com/appnotes.cfm/appnote_number/2034
>>
>>Atmel also has some chips that they claim to be secure, 
>>but I have not evaluated them in detail.
>>http://www.atmel.com/products/SecureM68HC05/
>>http://www.atmel.com/products/SecureAVR/Default.asp
>>http://www.atmel.com/products/SecureARM/Default.asp
>>
>>(I had some trouble finding pricing on the Dallas chips; 
>>if you get pricing, please post the information here.)
>
>Markus Kuhn has shown 1996 that the DS5002 is not very secure:
>http://www.cl.cam.ac.uk/~mgk25/kuhn-da.pdf
>http://www.cl.cam.ac.uk/Research/Security/studies/st-rs.html

Thanks!  Alas, I don't speak German; does the paper say whether
they were able to extract the entire contents, and if so how long
it took to do so?

>From the abstract, it appears that Mr. Kuhn conducted a form of
known plaintext attack on the DS5002 80-bit proprietary algorithm 
by looking at the encrypted instruction in RAM and what he figured 
that the instruction might be from looking at it's effect on the 
I/O.  The Dallas/Maxim DS5240/DS5250 uses DES or 3DES. As far as 
I know, DES is strong under a chosen plaintext attack and 3DES is
even stronger.  Also, the The Dallas/Maxim DS5240/DS5250 has 5K of 
internal Program/Data SRAM, so the engineer programming it should 
be able to make it difficult to associate a particular RAM access
with a particular I/O operation.

Here is the patent for these chips and some other info I found.
http://www.freepatentsonline.com/patents/us/551/5515540/5515540.pdf
http://www.rentron.com/Files/Dallas/secure.pdf

Guy Macon wrote:

> Thanks!  Alas, I don't speak German; does the paper say whether
> they were able to extract the entire contents, and if so how long
> it took to do so?

Services like Babel-Fish or Systran will translate the web-pages for which 
you provide URL's. I prefer Systran but you have to register to use. If you 
need translation for a large number of documents they will begin to charge.

-- 
********************************************************************
Paul E. Bennett ....................<email://peb@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/
********************************************************************

>> Markus Kuhn has shown 1996 that the DS5002 is not very secure:
>> http://www.cl.cam.ac.uk/~mgk25/kuhn-da.pdf
> does the paper say whether they were able to extract the entire 
> contents, and if so how long it took to do so?
Its not very clear how long ( typical & worst case ) and 
therefore i am sceptical if at all. 
  A RAM-emulator feeds the controller with data and hopes
to identify the opcodes. Specifically an opcode that writes one
of the 3 ports of the controller. Therefore apart from the
RAM-emulator the external machine has to watch if these 3 ports
change state. Several other opcodes are needed, but then one 
could present the controller with a very short program 
( page 34 ) to copy the content of the memory byte for byte 
through the controller to the parallelport.
Its not so clear how to get the other opcodes apart via
trial & error.
As the memorymap is scrambled too the actual system has
to use FIFOs to feed the opcodes. 

> DES or 3DES
Actually Dallas claimed its inital non-DES has a longer key
then DES and thereby is better. 

There are some valid points:
* Encoding per byte or only opcode-length 1 - 3 bytes 
  is not a good idea because it makes searching easier. 
  But the usual controller is optimized for these short 
  instructions. 
* If the controller has to access program memory externally
  the speed has to be fast to give acceptable performance
  for the application. But that makes searching faster too.
Requirements for controller and encryption collide
head to head in a system with external program-memory. 

Its claimed the DS5002 is used in ATMs 
( automated teller machines ):
Anderson, Bond "Cryptographic Processors - a Survey" 
                                        IEEE proceedings 
http://www.cl.cam.ac.uk/~mkb23/research/Survey.pdf

MfG  JRD

> Its not very clear how long ( typical & worst case ) and
> therefore i am sceptical if at all.

Read the paper more carefully.  2500 attempts @ 300 attempts per second for
the initial instruction is about 8.3 seconds, say 10.
Another second to test all 256 co0mbinations of this byte and tabulate the
results.
Inserting NOPs before the instruction might take another 10 seconds or so
per byte.  Say 650,000 seconds for the entire address space.  About 7.5 days
worst case (say half that on average).

Cheers,
Alf

>> Its not very clear how long ( typical & worst case ) 
> Read the paper more carefully. ...  About 7.5 days
> worst case (say half that on average).
And on which page of the report is that number ? 

MfG  JRD

> Thanks!  Alas, I don't speak German; does the paper say whether
> they were able to extract the entire contents, and if so how long
> it took to do so?
>

Heree's the English translation
http://www.cl.cam.ac.uk/users/rja14/tamper.html

and the sequel:
http://www.cl.cam.ac.uk/ftp/users/rja14/tamper2.ps.gz

Cheers,
Alf

The orginal text is the Diplomarbeit ( not quite a Ph.D 
but somewhat similar ) from Kuhn, 31. July 1996. Its 
making no specific claims. Seems the hardware is ready, 
and some tests of the software are on the way. 

> Heree's the English translation
> http://www.cl.cam.ac.uk/users/rja14/tamper.html
Thats not the translation.
Its a probably shortened version of:
  Ross Anderson, Markus Kuhn 
  "Its Tamper Resistance - a Cautionary Note"
  The Second USENIX Workshop on Electronic Commerce Proceedings,
  18. November 1996
  ... It won the best paper award at that conference."

Here are specific claims indeed:
  "One of us (Kuhn) has designed and demonstrated an effective    
   practical attack that has already yielded all the secrets of 
   some DS5002FP based systems used for pay-TV access control 
   and also broken a code lock provided as a challenge by the 
   German Federal Agency for Information Technology Security 
   (BSI)."
   "in fact we typically need less than 2,500 attempts."  
   "The details will be presented in a separate publication, ..."

> and the sequel:
> http://www.cl.cam.ac.uk/ftp/users/rja14/tamper2.ps.gz
That text
Anderson Kuhn "Low cost Attacks on Tamper Resistant Devices"
refers only to 
  Ross Anderson, Markus Kuhn 
  "Its Tamper Resistance - a Cautionary Note"
  and contains no technical detail.

MfG  JRD

Unbeliever wrote:
>
>> Its not very clear how long ( typical & worst case ) and
>> therefore i am sceptical if at all.
>
>Read the paper more carefully.  2500 attempts @ 300 attempts per 
>second for the initial instruction is about 8.3 seconds, say 10.
>Another second to test all 256 combinations of this byte and 
>tabulate the results.
>
>Inserting NOPs before the instruction might take another 10 
>seconds or so per byte.  Say 650,000 seconds for the entire 
>address space.  About 7.5 days worst case (say half that on 
>average).

..and, of course, the attacker can buy ten or a hundred of the 
devices and test them in parallel.