In the official guide at http://developer.android.com/tools/publishing/app-signing.html it is strongly recommended that developers use self-signed certificates valid until the year 2034, but using cryptographic algorithms that are not even secure for use in the year 2012, specifically that page strongly recommends (almost insists) that signing should be done with a combination of MD5 (completely broken!), SHA-1 (mostly broken, deprecated) and 2048 bit RSA (the minimum key length for use in 2012, way too weak for 2033).
This raises two obvious questions:
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)?
On Thu, Oct 4, 2012 at 2:23 PM, Jakob Bohm <jb-goo...@wisemo.com> wrote:
> In the official guide at
> http://developer.android.com/tools/publishing/app-signing.html it is
> strongly recommended that developers use self-signed certificates valid
> until the year 2034, but using cryptographic algorithms that are not even
> secure for use in the year 2012, specifically that page strongly recommends
> (almost insists) that signing should be done with a combination of MD5
> (completely broken!), SHA-1 (mostly broken, deprecated) and 2048 bit RSA
> (the minimum key length for use in 2012, way too weak for 2033).
> This raises two obvious questions:
> 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)?
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 <jb-g...@wisemo.com<javascript:>> > wrote: > > In the official guide at > > http://developer.android.com/tools/publishing/app-signing.html it is > > strongly recommended that developers use self-signed certificates valid > > until the year 2034, but using cryptographic algorithms that are not > even > > secure for use in the year 2012, specifically that page strongly > recommends > > (almost insists) that signing should be done with a combination of MD5 > > (completely broken!), SHA-1 (mostly broken, deprecated) and 2048 bit RSA > > (the minimum key length for use in 2012, way too weak for 2033).
> > This raises two obvious questions:
> > 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).
We do of cause 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.
On Sat, Oct 6, 2012 at 12:24 PM, Jakob Bohm <jb-goo...@wisemo.com> 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 <jb-g...@wisemo.com> 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.
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 <jb-g...@wisemo.com<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 <jb-g...@wisemo.com> 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.,
> 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.
On Tue, Oct 9, 2012 at 7:33 PM, Jakob Bohm <jb-goo...@wisemo.com> wrote:
> On Wednesday, October 10, 2012 12:45:56 AM UTC+2, Jeffrey Walton wrote:
>> [SNIP]
>> 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.
The developer can put nearly any information he/she wishes in the
account, including fictitious information.The information is not
checked. (The assurances on the relationship are similar to what we
have with non-EV certificates due to the race to the bottom.)
There are other distribution points and methods besides Goggle Play.
One can upload to any number of Application Stores:
https://www.google.com/search?q=android+alternate+application+stores.
Or, I can deliver it over SneakerNet and ask you to install via `adb
install <my program>`.
Plus, I can sign with the well known ANDROID DEBUG key. The program
will run just fine.
Self signed developer certificates were a design decision intended to
remove the barrier of entry. The only thing the signature is good for
is updates to published APKs. And as you pointed out, 1024-bit with
MD5 (the docs tell us to use MD5withRSA) means both the good guy and
bad guy will be able to update them.
> (The assurances on the relationship are similar to what we
> have with non-EV certificates due to the race to the bottom.)
Not true. EV certificates offer almost nothing and in fact the added
checks are worth less than the non-EV domain ownership check (never
heard of a dodgy accountant) and are really a way to make companies
worried about browser messages cough up money to the CAs, though
there are other major issues with SSL.
I could be wrong as I don't have an account but I believe the Google
user account may be more verifiable than the additional non-EV checks
as it is directly tied to a payment that can't be cash, though possibly
a fraudulent payment or the account hijacked etc..
'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'
