Hi!
We already know that embedded signatures [1] pose a challenge for
reproducible builds.
And it's not too hard to imagine a program detecting which key it's
signed with and changing its behaviour based on that; which I think is
inherently unavoidable.
But the Android APK Signature Scheme v2/v3
On Tue, 31 Jan 2023, FC Stegerman wrote:
> Hi!
>
> We already know that embedded signatures [1] pose a challenge for
> reproducible builds.
>
> And it's not too hard to imagine a program detecting which key it's
> signed with and changing its behaviour based on that; which I think is
> inherentl
* Nicolas Vigier [2023-01-31 11:42]:
> On Tue, 31 Jan 2023, FC Stegerman wrote:
> > We already know that embedded signatures [1] pose a challenge for
> > reproducible builds.
> >
> > And it's not too hard to imagine a program detecting which key it's
> > signed with and changing its behaviour base
> On Jan 31, 2023, at 5:18 PM, FC Stegerman wrote:
> ...
>
> We must thus ask ourselves "what is the program's environment"? I
> think environment variables, date/time, etc. are obviously part of the
> environment. As is anything involving networking and remote files.
>
> That we also need t
* "David A. Wheeler" [2023-02-01 01:38]:
> > On Jan 31, 2023, at 5:18 PM, FC Stegerman wrote:
> > We must thus ask ourselves "what is the program's environment"? I
> > think environment variables, date/time, etc. are obviously part of the
> > environment. As is anything involving networking and
> On Jan 31, 2023, at 8:59 PM, FC Stegerman wrote:
>
> Agreed. And I often wish Android had used detached signatures. Though
> detached signatures would have made distributing APKs more challenging:
> a single file is much more convenient for end users.
Sure, but the solution is trivial.
C
>> Agreed. And I often wish Android had used detached signatures.
>> Though detached signatures would have made distributing APKs more
>> challenging:
>> a single file is much more convenient for end users.
> Sure, but the solution is trivial.
> Create something that you want signed ("item A").
I recently noticed a similar vulnerability in the W3C MiniApp packaging draft,
whereby they embed signatures for the individual zip entries in the (legal)
padding between the final entry and the zip's central directory[1]. This seems
clever, but it means that only the individual entries, and n
I recommend that the reproducible-builds website have a short article
*specifically* recommending how signatures, OmniBOR data, & similar metadata
should be shared.
In short, do *NOT* embed such data (especially signatures) in complex formats
like ELF or PE.
Instead, create an archive with the "
* Marc Prud'hommeaux [2023-02-01 18:12]:
> I recently noticed a similar vulnerability in the W3C MiniApp
> packaging draft [...]
Interesting, thanks for the info!
> But in the context of an Android app, where it sounds like it has
> runtime access to the original .apk artifact and signing data, t
* "David A. Wheeler" [2023-02-01 17:20]:
> > Agreed. And I often wish Android had used detached signatures. Though
> > detached signatures would have made distributing APKs more challenging:
> > a single file is much more convenient for end users.
>
> Sure, but the solution is trivial.
>
> Cre
> On Feb 1, 2023, at 2:07 PM, FC Stegerman wrote:
>
> * "David A. Wheeler" [2023-02-01 17:20]:
>>> Agreed. And I often wish Android had used detached signatures. Though
>>> detached signatures would have made distributing APKs more challenging:
>>> a single file is much more convenient for
On Wed, Feb 01, 2023 at 02:48:15PM -0500, David A. Wheeler wrote:
>
>
> > On Feb 1, 2023, at 2:07 PM, FC Stegerman wrote:
> >
> > * "David A. Wheeler" [2023-02-01 17:20]:
> >>> Agreed. And I often wish Android had used detached signatures. Though
> >>> detached signatures would have made dis
> On Feb 1, 2023, at 13:40, FC Stegerman wrote:
>
> * Marc Prud'hommeaux [2023-02-01 18:12]:
>> I recently noticed a similar vulnerability in the W3C MiniApp
>> packaging draft [...]
>
> Interesting, thanks for the info!
>
>> But in the context of an Android app, where it sounds like it has
On Wed, Feb 01, 2023 at 12:53:24PM -0500, David A. Wheeler wrote:
> I recommend that the reproducible-builds website have a short article
> *specifically* recommending how signatures, OmniBOR data, & similar metadata
> should be shared.
[...]
> Is there agreement on adding such a page?
Yes, I'd s
[... some context elided since this is getting quite long ...]
* "David A. Wheeler" [2023-02-01 20:48]:
> > Unfortunately, you've left out the details of the archive format here,
> > when they are actually quite important.
> >
> > You now need to unpack an archive (e.g. a .zip or .tar) before yo
> 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.
> On Feb 1, 2023, at 6:48 PM, Orians, Jeremiah (DTMB)
> 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
>
On Wed, Feb 01, 2023 at 08:40:46PM -0500, David A. Wheeler wrote:
> Maybe call it "Ways to combine reproducible builds with signatures and other
> metadata"?
"other metadata" brings .buildinfo files^w^wSBOMs to my mind and indeed we
have (at least) two concepts here, including the .buildinfo int
This W3C MiniApp format sounds a lot like JAR signatures, aka APK v1 signatures.
Although not an ideal format, it is at least well understood and explored.
As for some background on why APK v2/v3 signatures have this spot to stick data
in the signing block, the Android team developed a sche
* Hans-Christoph Steiner [2023-02-03 07:58]:
> This W3C MiniApp format sounds a lot like JAR signatures, aka APK v1
> signatures. Although not an ideal format, it is at least well understood
> and explored.
Actually, "between the final entry and the zip's central directory" is
exactly where the
If it is any consolation, I've done some review of large sets of malware apps.
They are not using any of these spots to hide stuff, from what I've seen. They
gold standard for malware is to not include the key code at all, and instead
download it at runtime. Some "enterprise" apps do that a
22 matches
Mail list logo
