ubuntu-appstore-developers team mailing list archive

[Marc Deslauriers <marc.deslauriers@xxxxxxxxxxxxx>]

On 13-06-06 10:40 AM, David Pitkin wrote:
> Marc I think there is one other thing which is that the app being
> submitted to the store actually game from the developer. This is an
> important thing and simply a login is mostly insufficient from a strong
> security perspective which is why developers have been signing apps even
> if its somewhat painful.
> 
> David

Yes, that's why I mentioned we require two things:

1- Guarantee that the app actually came from the developer

This establishes trust between the developer and the custodian of the
trusted app store. This is done either by signing the package itself, or
signing the hash of the package. For deb packages, we currently require
the uploader to sign the .changes file which contains the hash to the
package.

If we can get the package itself to be signed, it may be easier.

2- Guarantee that the app actually came from the trusted app store

This establishes trust between the end user and the app store. It
indirectly establishes trust between the end user and the app developer.

This is usually done by having the app store sign package hashes.

Marc.



> 
> On Thu, Jun 6, 2013 at 10:27 AM, Marc Deslauriers
> <marc.deslauriers@xxxxxxxxxxxxx <mailto:marc.deslauriers@xxxxxxxxxxxxx>>
> wrote:
> 
>     Hi!
> 
>     On 13-06-05 11:39 AM, Loïc Minier wrote:
>     >         Hi all!
>     >
>     > as a followup to a chat with Stuart, Colin, Martin and others it
>     > appeared that we need to agree on package signatures and I wanted
>     to get
>     > input from this list.
>     >   This topic is mostly about guaranteeing authenticity of the package,
>     > to deliver it securely so that it can be trusted by the client.
> 
>     There are actually two different things here:
>     - Guaranteeing that the app actually came from the developer
>     - Guaranteeing that the app actually came from the trusted app store
> 
>     >
>     >
>     > There are generally two ways to approach this:
>     > 1. package is always transported securely: developer uploads package
>     >    to appstore over https, appstore serves it over some secure channel
>     >    (could be https too) to clients
>     >
>     > or
>     >
>     > 2. signature is embedded in the package at build time (developer
>     >    workstation) and verified on the client[1]
> 
>     I think you're missing the most important scenario:
> 
>     3. signature is on a package list which contains a crypto hash of each
>     individual package.
> 
> 
>     >
>     >
>     > The current approach with .deb packages served by APT is of the first
>     > type; approaches on other mobile OSes are more commonly of the second
>     > type where you can host e.g. an .apk on your personal website.
> 
>     Actually, it's of the third type. We distribute .deb packages over http,
>     not over a secure transport.
> 
>     Mobile devices typically have the application author sign his package,
>     which is then hosted in the official app store using approach #3.
> 
>     On iOS, you can't load packages that don't come from the trusted store
>     (with a few exceptions, for example, if you obtain an enterprise cert
>     from apple for homemade apps)
> 
>     On Android, you can't load packages that don't come from the trusted
>     store _unless_ you go into the settings and specifically check the box
>     to enable installing untrusted apps after clicking through a warning.
>     Many carriers disable this option.
> 
>     If you can install applications without going through a trusted app
>     store, you become vulnerable to malware and security issues.
> 
>     >
>     >
>     > Concerning the secure transport option, https or generally SSL are
>     a bit
>     > of a concern due to various attacks and problems with root
>     certification
>     > authorities.  This might be mitigated by DNSSEC and/or independent
>     > generation/management of certificates.
> 
>     Yes, especially on mobile devices where you cannot easily push out an
>     update to blacklist compromised CAs.
> 
>     >
>     >
>     > Concerning the signed package approach, here are a couple of
>     > implementations that would make it possible to sign the manifest
>     and all
>     > the package contents:
>     > a. dpkg-sig[2]; I believe this generates an index called "digests"
>     of the
>     >    components of the ar file with corresponding SHA1 and MD5 hashes,
>     >    then adds a GPG signature of that file as digests.asc to the
>     >    archive
>     >
>     > b. GPG signing the .deb directly
>     >
>     >
>     > One thing which the signed packages approach make harder is to build
>     > packages in a PPA; you'd have to build native packages locally and
>     sign
>     > them, or fetch them securely from your PPA then sign them.  But
>     > supporting multiple architectures is probably a larger discussion that
>     > we want to have separately, e.g. we don't have direct support for
>     Click
>     > packages coming out of PPAs.
> 
>     This is only to ensure that the package comes from a particular
>     developer, not to indicate if a package is from a trusted app store.
> 
>     >
>     >
>     > I'm personally in favor of generating packages with embedded
>     signatures
>     > which you can then share on the web, send directly to your device
>     etc.,
>     > and an approach similar to dpkg-sig would seem fine to me, but I'm
>     > curious to read what others think of the pros and cons of each
>     approach.
> 
>     I hope we're talking about an android-type option targeted mainly at
>     developers. I definitely wouldn't want regular users to be able to
>     install untrusted packages from a web page by default. There is no way
>     for us to maintain a device with a level of security comparable to iOS
>     or default Android if we allow doing that.
> 
>     >
>     >     Cheers,
>     >
>     > [1] /usr/share/keyrings/debian-keyring.gpg is 44M for ~1000
>     signatures,
>     >     so non-trivial size but probably due to signatures; if it's a
>     >     problem we could either just ship fingerprints of truster
>     developers
>     >     and fetch keys as needed, or resign the signed .debs that are
>     on the
>     >     app store
> 
>     We shouldn't require devices to validate developer signatures. There's
>     no easy way of knowing which developer is trusted, and no easy way of
>     updating those keys. Devices should simply validate the signature on the
>     hash given by the official app store.
> 
> 
>     Marc.
> 
> 
>     --
>     Mailing list: https://launchpad.net/~ubuntu-appstore-developers
>     Post to     : ubuntu-appstore-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:ubuntu-appstore-developers@xxxxxxxxxxxxxxxxxxx>
>     Unsubscribe : https://launchpad.net/~ubuntu-appstore-developers
>     More help   : https://help.launchpad.net/ListHelp
> 
> 
>