On Sat, Oct 6, 2012 at 12:24 PM, Jakob Bohm <[email protected]> wrote: > > On Friday, October 5, 2012 11:14:18 PM UTC+2, Jeffrey Walton wrote: >> >> On Thu, Oct 4, 2012 at 2:23 PM, Jakob Bohm <[email protected]> wrote: >> > [SNIP] >> > >> > 1. Why hasn't that page been updated to reflect the "current" state of >> > the art? >> > >> > 2. What are the maximum key and algorithm strengths supported by the apk >> > verification code in different Android versions (For instance an apk >> > that is >> > supposed to be compatible with Android 2.1 devices is limited to >> > whatever >> > strength Android 2.1 can verify, but another apk that has a minimum >> > system >> > requirement of Android 3.0 anyway is only limited by whatever Android >> > 3.0 >> > and later can verify)? >> There's a bug report for that: "Keytool and Default Keysize for >> Signing Apps," https://code.google.com/p/android/issues/detail?id=35327. > > That is a surprisingly recent bug report for such an obvious security > problem. > >> A while back I tested a 3072 modulus on an HTC EVO 4G running Android >> 4.0 or 4.1 (all OK). I did not test on older versions. >> > I have read rumors of a few people using 8192 bit modulus for signing some > apps, but I really would like to know the limitations of various "upstream" > android versions, so I can set my key length according to the lowest android > release supported for other reasons. (It would be sad to write tons of code > designed to work on for example all post 2.1.3 versions, and then > accidentally > sign it with a key that can only be accepted by 2.3.4 or later, and it would > be > equally sad to use a weak key needed only for compatibility with Android 1.6 > if the code won't run on 1.6 anyway). I think 8192 is a bit extreme since it appears we only need 128 bits of security for the 2030s (according to NIST, NESSIE, ECRYPT, et al). Also, Michael brought up a good point of SHA-256 to maintain security levels (I don't recall if I tested with SHA-1 or SHA-256).
You should also look at the threat model. [Partially] signed APKs only provide the ability to update a previously published APK. The APK can be updated *IFF* it was previously published under the same signing key. In essence, the threat here is the bad guy will be able to provide an update to a good guy's code (which can be farily troublesome). Due to the signing model and process, there is no effective identity assurances for the users of the APK. So we will never really know who the good guy or bad guy is/was. I say "partially signed" because the signing process violates Schneier and Wagner's semantic authentication (http://www.schneier.com/paper-ssl.html). Confer: one signs an APK, then zip aligns the APK. Will anyone be surprised when Apple and Android code signing fails in the field like http://www.kb.cert.org/vuls/id/845620? Or perhaps un-signed data will be used/consumed by an application? > We do of course have a "zoo" of old phones for testing, but without > documentation (or at least a pointer to the relevant files in GIT), it is > hard to > tell if something works on all phones of that generation or only on the > specific > model/configuration/firmware in the zoo. I think its easiest to (1) test in the simulator and (2) validate the test results (from the simulator) on real hardware if you have the hardware available. I maintain devices with Android 2.3, 3.0, 4.0 and 4.1 for validation. Regarding documentation, its not possible to browse Google/AOSP maintained sources online (cf., http://stackoverflow.com/questions/449763/where-can-i-browse-android-source-code-on-line). But you can always check out a local copy. Jeff -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
