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
> 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.
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.