hiding data/code in Android APK embedded signatures

David A. Wheeler dwheeler at dwheeler.com
Thu Feb 2 01:40:46 UTC 2023



> On Feb 1, 2023, at 6:48 PM, Orians, Jeremiah (DTMB) <OriansJ at michigan.gov> wrote:
> 
>> Last I checked, CVE-2007-4559 is still not fixed; and surely not the only unfixed (let alone currently unknown) 
>> such vulnerability that may suddenly become a problem when you switch to a scheme where you need to
>> unpack an archive before you can verify the authenticity of its contents.
> Ok, I propose the following archive format which is immune from all such classes of attacks:
> A gpg --armor crypto-signature of your choice
> 4 null bytes (just in case we want to extend this scheme; otherwise a single null byte will do)
> A base64 of any archive format you want

Fair point!

I would want to support multiple signatures, but that isn't a killer.
You could modify the scheme to allow multiple signatures easily enough, e.g.,
\0\0\0\0 if the next one is the payload, and \0\0\001\001 (or some other scheme) if
the next one is also a signature. That variant is still trivial to create (cat) and to unpack.

This specific one requires gpg, which is a non-starter for many people, but there are other
signature formats as well.

SO:

I think this discussion shows that there's a need for a page, but instead of advocating a particular position,
it sounds like it should list various ways to use both signatures (or other metadata)
and the data which is supposed to be reproducible, along with each way's pros & cons.

Maybe call it "Ways to combine reproducible builds with signatures and other metadata"?

--- David A. Wheeler



More information about the rb-general mailing list