On Wednesday, October 10, 2012 12:45:56 AM UTC+2, Jeffrey Walton wrote: > > On Sat, Oct 6, 2012 at 12:24 PM, Jakob Bohm <[email protected]<javascript:>> > 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). >
Yes, I just mentioned a data point I found, I was not suggesting it was a good choice of length. > 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. > There is an additional identity binding: When an apk is uploaded to Google Play, the uploaded APK, and thus its embedded key, is bound to the Google account of the developer who uploaded the APK, and this identity is presented to the end user before the initial download. Similar if the initial APK is provided to the end user by any other authenticated means. > > 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? > > That CVE entry is about incorrect signature verification at a very different level. You would be better off finding a page about the Authenticode 1.0 bug that did not cover the appended packed data in signing/verifying some brands of self-extracting compressed files (this has long since been fixed). As for completeness, I believe the jar signing model is that the signature is done on the *contents* of the zip file, not on the zip container and its compression (so the recipient will need non-exploitable unzip code to safely verify the signature). Now there is a potential question (off topic in this thread) if the apk verification code remembers to reject apks that contain files not listed in the signature data and/or lacks files listed there. There is also a potential question (off topic in this thread) as to what the apk verification code should do about files whose name indicate they could be the signed hashes made using an algorithm yet to be invented (such as SHA-4). If the apk verification code rejects such apks, it becomes impossible to introduce stronger hash algorithms in a backward compatible manner, if the apk verification code lets such files pass through, there is a risk that they could be used as (yet another) subliminal channel for passing data to the code whose signature was verified. Given all the other places where such subliminal messages could be hidden, this is mostly a non-issue. > 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. > > Downloading code from GIT is not much of a problem, examining someone else's millions of lines of code and making reliable conclusions about the codes behavior is a much bigger problem compared to asking someone who already knows that code inside out. -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To view this discussion on the web visit https://groups.google.com/d/msg/android-security-discuss/-/gYwv1J7Gn1oJ. 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.
