ubuntu-appstore-developers team mailing list archive

[Loïc Minier <loic.minier@xxxxxxxxxxxxx>]

On Thu, Jun 06, 2013, Marc Deslauriers wrote:
> >   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

Thanks for being more rigorous than me in defining these; I tried to
capture things we had discussed yesterday, but we need to agree on what
we're trying to protect exactly.

Maybe we can even go one step further from the above two things and try
to list stakeholders and use cases; we have 3 stakeholders (users,
appstore owners and developers).

Users typically use devices with initially a single trusted appstore
configured; they don't want to get any malware but:
 * it might make sense to allow them to add trusted appstores; perhaps
   this is blocked in the default config, but it might make sense in an
   OEM scenario, or we could decide that we don't want to support this
   at all

 * they might want to install apps manually instead of visiting an
   appstore; for instance this could be the way developers test their
   own apps before submitting them or when developing updates, this
   could be a way to get some beta-testing from developers directly to
   the users, or a way for users to install apps that have been removed
   from the appstore
   - depending on the implementation, we might be able to verify
     signatures of manually installed packages or not
   - we obviously must reject any unsigned or untrusted package by
     default

> > 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.

I actually considered this approach part of 1., typically what we're
doing today for .debs: signed Packages indices are a mean to deliver an
unsigned .deb securely to end-users.  But fair enough, you could make
this a separate category as "transported securely" is indeed confusing
here as we use http for .debs today.  The main split I wanted to
emphasise was on building the signature at build-time in the payload
(2.) or on transporting the payload securely from one place to the next
(1.).

> 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)

You can also install them from iTunes; I think you can install old
versions from their .ipa files in this way.

Similary on Android you can update an installed package with an .apk;
I've noticed that it checks that the key used to sign the package is the
same as the one that was used to sign the currently installed package,
but I'm not sure what other checks are in place.

> 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.

I think we typcally want something similar, it's not clear to me whether
we want to allow carriers to disable installation of untrusted apps
entirely nor whether we want to allow them to add extra appstores, but I
guess these are relatively trivial settings.  It's more of a product
question, whether we allow the ecosystem to be bent in dangerous ways
and then still calling this Ubuntu.

> 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.

This is a very good point that I think we've missed yesterday; I guess
the approach I was indirectly describing as a possible implementation
assumed that developers created keys, uploaded them to the appstore, and
we distributed the trusted keys to the devices.  But that would allow
developers to distribute apps we haven't reviewed through other
channels, which I think is not ok.

So you have a point that we'd need some *appstore* trust path on top of
the developer signature in the package, but this goes against one of the
fundamental assumptions we were taking until now: that the package is
untouched from the developer.

Still, we would at least want to allow developers to deploy apps to
their own device for testing, preferably without disabling security
entirely.

Would it work to combine signed indices with developer keys?  e.g.:
 * by default, users can only install apps which are listed in the
   official appstore (signed) index
 * when they do, this gets the developer key from the appstore and
   verifies the package against the index hash and the developer
   signature
 * users may install updates of installed packages /signed with the same
   developer key/ by other means
 * developers might turn on developer mode and push their developer key
   and apps signed with this key to local devices

 * don't think we want this: users may turn off any verification and
   install untrusted packages

  * trusting extra appstores can only be done with custom builds of
    Ubuntu Touch

> 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.

(Yup)

> 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.

It's kind of weak to only check appstore hashes when you consider apps
not distributed via the appstore.

Something related we had discussed yesterday is how do we namespace apps
and prevent squatting names (e.g. how do you prevent someone to take
"myapp" as appname, or if you are the one owning com.ubuntu.phone, how
do you prevent someone from using the same app name or naming things
under your realm).
  I mention this because I think that even if we allow local
installation of apps for e.g. developers, we would want to prevent
replacing an official app with a locally built app with the same name.
(We excluded GUIDs because these are ugly in the filesystem for the
convergence case.)

    Cheers,
-- 
Loïc Minier