Thnaks Brian,
On Sun, Jul 22, 2012 at 2:50 AM, Brian Carlstrom <[email protected]> wrote:
> APKs just use jar signing. A quick review of
> http://docs.oracle.com/javase/tutorial/deployment/jar/intro.html suggests
> there are signatures for each of the file contents to ensure individual
> entries are not tampered with, and a signature on the manifest of file
> contents, to make sure entries aren't added or deleted.
>
> i haven't looked a the how's or why's of zipalign, but if it is just padding
> zip entries or the zip directory to be aligned to speed access, this change
> of layout of entries in the file shoudn't affect the signatures. as far as
> why Sun did this instead of just treating the zip as a blob to sign, i'm
> guessing it easier to make signed jars look like regular jars for most
> purposes.
This is probably a dumb question, but doesn't Sun/Oracle realize they
broke Semantic Authentication? Semantic Authentication was intorduced
by Wagner and Schneier and also known as The Horton Principal.
"Analysis of the SSL 3.0 protocol," www.schneier.com/paper-ssl.pdf.
It almost sounds as though they made the same mistake as SSL v2:
SSL 2.0 suffered from at least one flaw along these
lines: it included padding data but not the length of
the padding in the MAC input, so an active attacker
could manipulate the cleartext padding length field
to compromise message integrity.
I often use the contrapositive ("if not q, then not p") when analyzing
protocols to remove unneeded fields in a protocol - if a field is not
encrypted nor authenticated, then it has no value and and should be
removed from the protocol. If folks object to a field's removal (ie,
they claim its necessary) then the field needs either encryption or
authentication.
Jeff
> On Sat, Jul 21, 2012 at 10:23 PM, Jeffrey Walton <[email protected]> wrote:
>>
>> Hi All,
>>
>> I was reading about zipalign
>> (http://developer.android.com/tools/help/zipalign.html). The docs
>> state:
>>
>> Caution: zipalign must only be performed after the
>> .apk file has been signed with your private key. If
>> you perform zipalign before signing, then the signing
>> procedure will undo the alignment.
>>
>> Intuitively, I would expect alignment adjustments and then code
>> signing, presuming zipalign would modify one or more files in the APK.
>> Since zipalign occurs after code signing, it tells me there are
>> non-signed fields in the APK file (or zipalign is a do-nothing
>> process).
>>
>> A partially signed APK begs the question, what precisely is signed?
>> App-Signing
>> (http://developer.android.com/tools/publishing/app-signing.html)
>> does not cover the topic.
--
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.
