[Cryptography] Android's Secure ADB as a security hole

Peter Gutmann pgut001 at cs.auckland.ac.nz
Wed Jan 28 10:34:31 EST 2015

Sami Tolvanen <sami-cryptography at tolvanen.com> writes:

>I agree with Ben that this doesn't seem like a very big problem at the
>moment, but I nevertheless merged a fix to Android today, which should find
>its way into upcoming releases:

Great :-).  A better long-term fix though would be to borrow something from
Abadi and Needham's "Prudent Engineering Practice for Cryptographic
Protocols", and specifically take Principle 1 which says:
  Every message should say what it means. The interpretation of the message
  should depend only on its content. If the identity of an agent is essential
  to the meaning of a message, then the message should mention that agent

The ADB design violates this rule, since the message is totally opaque.  The
spec says it should be 20 random bytes, but that also makes it
indistinguishable from a SHA-1 hash of a message, which is a message type
that's used very widely in signatures.  So it's still a signing oracle, just a
somewhat more restricted one.

A better solution would be to add something to what's being signed that's
controlled solely by the signer, so that the client can no longer force the
signer to sign whatever it wants:

  sign( "ADB authentication" || nonce || ADB_AUTH_TOKEN )

(the nonce is to make sure that the signer never signs a predictable-to-the-
client value, possibly overkill but if "MD5 considered harmful today" is
updated at some point to become "SHA-1 considered harmful today" then it'll
save your bacon.  The downside is that you'll need to communicate the nonce
back to the client for when they verify the signature.  Also, if you really
wanted to do it properly, you could make it a Halevi-Krawczyk hash/RMX...).


More information about the cryptography mailing list