CPRNGs are still an issue.

Peter Gutmann pgut001 at cs.auckland.ac.nz
Tue Dec 16 23:07:22 EST 2008


Bill Frantz <frantz at pwpconsult.com> writes:

>I find myself in this situation with a design I'm working on. I have an ARM
>chip, where each chip has two unique numbers burned into the chip for a total
>of 160 bits. I don't think I can really depend on these numbers being secret,
>since the chip designers thought they would be useful for DRM. It certainly
>will do no harm to hash them into the pool, and give them a zero entropy
>weight.

The ARM family are particularly problematic for entropy gathering because
anything that'd help you is (a) locked away so it can't be accessed and (b)
not easily ascertainable at runtime.  For the x86 equivalent you just do a
CPUID (and you can in turn check whether the architecture supports that before
you use it if you're on an old-enough system) and from there can execute
further instructions to determine hardware capabilities and read/use them via
MSRs as required.

For the ARM the equivalent is a CP15 read (and then further accesses to the
ARM equivalent of x86 MSRs), e.g.:

  asm volatile (
      "mrc p15, 0, r0, c0, c0, 0\n\t"
      "str r0, %0\n"
      : "=m"(processorID)
      :
      : "cc", "r0");

but this is only accessible in supervisor mode so for any normal app it's an
instant illegal instruction fault.  Furthermore, even in supervisor mode
there's no way to bootstrap your way up as you can for x86 and tap the amazing
store of hard-to-predict information that most ARM cores make available
because each ARM implementation adds its own oddball registers and the only
way to know whether they're present and usable is if you know in advance which
specific core and stepping you're working with.  In other words you can't get
there from here and even if you could you wouldn't know what to do when you
got there.  So everything you need is there, you just can't use it.

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list