Apps/Security/Distribution

From MozillaWiki
< Apps‎ | Security
Jump to: navigation, search

Secure Application Distribution

This section defines how trust is to be established between all four parties: B2G developers, Application developers, users and stores.

Requirements

Distribution / management of WebApps

  1. It should not be trivially easy for a rogue application to be listed on a marketplace / store
  2. The development and release history of an application, including the identity of the developer, should be fully accountable.
  3. A store may revoke a bad / malicious WebApp
  4. A user may revoke a bad / malicious WebApp.
  5. A store may not install ("push") apps onto a device without the user's expressed and explicit permission
  6. A user may remove any app at any time.
  7. A telco can decide which stores to implicitly trust on devices that they sell. (an analogy in debian packaging terms is that the telco sets the initial contents of the /etc/apt/sources.list file)
  8. A user must be able to override the stores which they decide to implicity trust on their devices. (an analogy in debian packaging terms is that the user should be free to change the contents of the /etc/apt/sources.list file)
  9. The distribution of applications must scale to mass-volume proportions (100 million or more phones; 1 million or more store-distributed application downloads or updates per day)
  10. The development of applications must be straightforward, and rapid development cycles must be easy.
  11. The security measures chosen to underpin the distribution of applications through stores must not interfere with, or make awkward, the development of applications.
  12. The development of applications by any developer must not interfere with or compromise the security measures or the distribution of applications through stores.
  13. A developer's application should not, through any technical measure, technical limitation or design flaw in the security model, be restricted to sole and exclusive distribution through any one given and specific store.
  14. Distribution of commonly-used libraries (B2G UI libraries/widget-sets, jquery, prototype, node.js) needs to be controlled and managed
    • multiple versions of the same library need to be permitted, but only one copy of each version of that library permitted
    • there needs to be a way to express dependencies
    • reference counting needs to be added so that when packages are removed, its dependencies are also removed if they are also no longer required.

Proposals

W3C XML Digital Signatures for Widgets

The W3C has a standard for XML Widget Digital Signatures that, on close inspection, shows that it fulfils the requirements. This diagram shows the relationships:

Digsigchain.png

"Stores" correspond to the W3C's definition of "Distributors"; authors correspond to the B2G concept of "app developer".

The only problem with the W3C XML Widget Digital Signature Standard is that, compared to the infrastructure behind GNU/Linux Distributions, which have been deploying Chained-Signing for some considerable time and have a decades-long complete architecture, the W3C's standard was only ratified in late 2011. However, here are some implementations:

  • Java javax.xml.crypto.dsig package: this appears to solely implement the Cryptographic portions of the API: it does not implement a complete store, nor any infrastructure for validating the packages, nor any infrastructure for downloading or distribution of packages.
  • There is a GSoC project to implement it in Apache Wookie, which already has student interest. There is therefore a strong possibility that an open source implementation will exist by the end of Summmer 2012.

On the commercial side, the W3C XML Widget Digital Sigature has been implemented by Opera, Nokia, Vodafone, Samsung, Obigo, RIM and a bunch of web TV platforms as its part of a lot of other spec stacks in the mobile and TV space such as WAC, MPEG-U, HbbTV, CMX (etc).

There have been some packaging and signing tools supporting the specs issued as part of SDKs, e.g. the Vodafone widget packager and the WAC SDK (possibly written by Samsung/Limo). The Blackberry webapps signing tools may also uses widgets-digsig as Blackberry Widgets are W3C Widgets. RIM may have RIM open-sourced most of their Widgets code last year so that may be another lead.

Trusted store with permissions delegation

Note: Last updated March 14, 2012
  • Mozilla (telco store) acts as an authority for permissions requests
  • WebApps request permissions in manifest
  • Each store contains a set of permissions they can grant
  • The "root" store may grant any permissions
  • A store (parent) may permit a trusted store (child) to grant a subset of parent's permissions
    • Note: This is opposite of the FLASK model which does not use a permissions hierarchy. There are problems if a child store inadvertently grants too permissive of permissions to an app (genie out of the bottle).
    • ACME is a root store
    • ACME allows Roadrunner Store to grant (Throw, Eat) permissions to WebApps it trusts
    • Roadrunner Store may further permit Coyote store a subset of (Throw, Eat) permissions
    • Coyote Store may then grant WebApps it trust a subset of what Roadrunner Store granted
  • Permissions granted to a WebApp are the intersection of permissions requested by manifest and permissions a store may grant
    • WidgetIncApp is listed on ACME store
    • WidgetIncApp requests Hammer, Nail permissions
    • ACME store has been granted Hammer, Screw permissions by telco
    • WidgetIncApp receives (Hammer, Nail)∩(Hammer, Screw) == Hammer permissions
    • There was discussion of a "privileged store" which is a store blessed to allow access to certain APIs such as dialer
    • "blessed" apps must always be served from the store with access to source code
  • Selfhosting of WebApp
    • A WebApp can be self-hosted and query a trusted store on install
    • The WebApp will be granted permissions based on what the trusted store would have granted the WebApp
      • WidgetInc wants to host WidgetIncApp from widget.lol
      • WidgetInc has already uploaded WidgetIncApp to ACME Store
      • User visits widget.lol to install WidgetIncApp which contains a pointer to ACME Store
      • Runtime queries ACME Store to see what permissions should be given to WidgetIncApp

Debian Keyring (Package Management) for distribution of apps

The primary advantage of apt (or yum) package distribution is that it uses person-orientated PKI as the fundamental basis of trust. By contrast, SSL PKI is host-based and thus any distribution model that relies solely on SSL PKI will be tied solely and exclusively to that host. Debian packages, however, being GPG-signed by people, can be distributed without limit or restriction, not even requiring a network (CD or other offline media is possible and supported).

  • Last updated March 22, 2012
  • Items in () denote the equivalent in WebApp world
  • infrastructure already exists
  • Code is cryptographically signed by multiple parties
    • Package (WebApp) maintainer (author / company)
    • Package is signed by FTP masters (marketplace / store)
  • Signed packages / manifests are separate from binaries (HTML content)
    • We need a way to verify that the WebApp content has not changed: each package has an MD5 and SHA1 checksum.
  • The runtime checks that the binary+signature match and that the signature originates from a trusted public key (of the store)
  • A user may choose to add more sources (stores)
  • A user must add the source's keyring (an app that contains the store's public key(s)) to disable warning about untrusted source
  • To compromise an app with proper code signing requires the following extremely difficult tasks to be carried out:
    1. compromise the site hosting the app
    2. compromise the keys - both the developer's *and* FTP master (marketplace/store) signing the app
    3. compromise or trigger the update mechanism for the app
    4. wait for updates to trickle out without anyone noticing the previous steps.

dealing with rogue applications

this section covers how an application may be replaced if discovered to be malicious

  • automatic updates must be enabled (apt-get upgrade)
  • people who wish to remain on a "stable" store must have a security-line equivalent to "deb http://security.debian.org/.... "
  • rogue applications have a package with a version number "1 higher" than the rogue application's previous package
  • the updated package can:
    • be a properly bug-fixed version
    • contain warnings that the user must explicitly agree to prior to acceptance
    • in extreme cases simply replace the files with a blank app that announces "This Application Caused Serious Problems, It Had To Go, Make Sure You Check Your Data N System N Stuff".
    • be a completely new name (recommended beginning with "blacklist-") if required. see http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

debconf shim for B2G / gaia apps

This section is best understood after examining an existing debconf frontend such as debconf-kde-helper in debian, or ubiquity-frontend-debconf in ubuntu. There is also an application in debian called "gkdebconf" which should also be examined. All of these applications communicate with debconf whilst applications are being installed and configured. The front-end deals with presentation of questions to the user, and relays their responses to the installation process.

The proposal is therefore very simply to write a debconf front-end which is also a gaia application. Below is a description of the process.

  1. a user goes to a store (GUI front-end TBD)
  2. this "store" triggers the command "sudo apt-get update" in the background (or this occurs on a regular basis)
  3. they go "i wanna app wiv a cherry on top"
  4. the selection fires off a LOCAL COMMAND "sudo apt-get install cherry-on-top".
  5. the GUI uses the dpkg / debconf communication system to inform them of progress
  6. the GUI then walks them through the security questions (which is all part of debconf)
  • we would distribute a debconf frontend app for B2G
  • B2G app communicates with dpkg/debconf through something like a unix pipe
  • the fetching of the app is an implementation detail, FTP, rsync, HTTPS doesn't matter as long as the package is properly signed
  • B2G app only receives progress updates
  • it may be possible to leverage the existing Debian package infrastructure
    • Note: If leveraging the good-will of debian to host B2G and also Gaia apps, there may be license (advertising clause) issues that need to be resolved

New URI proposal (apt:// or yum://)

This is a very simple proposal to allow applications to be installed in a familiar way (URLs) yet allow the installation process to go through security checks with the minimum of additional programming and modifications to the B2G codebase. A URI could be embedded into application pages (JS or static HTML) for example "apt://phonedialer".

In the instance where that application - phonedialer - has already been installed, the application is activated. However, if the application has not been installed, B2G would hand off the command to apt (or yum, if yum is selected instead). Instead of firing up the application, the debconf shim (see section above) would be activated. This would show the download progress (of both the package and its dependencies), check the digital signatures, run through the installation process including presenting the security questions. Finally at the end, the debconf B2G-aware front-end would be closed, and the application opened up instead.

The syntax for the URI could also be extended to include the specific version of the package to be installed (if required). apt://packagename?version=1.2.1 for example. Also, different archives (stores) could be specified. Doing so would require an additional step in the installation process to add that store to the /etc/apt/sources.list file, requiring the permission of the user before doing so.

Overall this approach has several technical advantages as well as being very simple to understand. If a package is wanted, put "apt://{packagename}" in a B2G web page, anywhere online. B2G devices will know what to do, and will install the package if it's not already available.

For developers however the deployment of the infrastructure required to host an entire debian archive may be too much. In such circumstances however there is a very simple additional proposition which takes care of that: either a deb:// URI or simply to activate installation and execution of packages when a "http://{fqp}/packagename.deb" URL is encountered.

Advantages of People-based security

  • developer keys are part of a comprehensive GPG/PGP web-of-trust that ensures that developers are actually who they say they are.
  • the procedure for stores to identify developers, through that web-of-trust of GPG/PGP keys, is very straightforward (and can be automated, although full automation without some degree of responsible vetting is not recommended).
    • a store could, on discovering a deliberately-malicious app, report the identity of the person directly to law enforcement authorities as well as to the web-of-trust.
  • developers can be requested to GPG-sign an agreement which becomes a legally-binding contract with the store(s). this is similar to CSP. Debian Developers actually do this, very comprehensively: http://wiki.debian.org/DebianMaintainer
  • the security can be upgraded on a rolling basis
    • developers can publish multiple keys into the online keyring, and use the old (less secure?) one whilst they are still establishing the new one in the webring. (note: this has actually happened in debian: a flaw was discovered in openssl and entire teams of GNU/Linux maintainers had to create new keys and revoke the old ones).
    • the "package keyring" can have new keys added to it as well; again, the old key can be used until the new (stronger?) one is well-established.
  • as the store's GPG key is used to digitally-sign "Package Release Manifests", including security update manifests, stable package-list manifests and "bleeding edge" package manifests, users can correspondingly always either roll back to a stable baseline, track security updates (only) or live on the edge, at their own choosing. (see http://ftp.uk.debian.org/debian/dists/Debian6.0.4/, note the "Release" file and its corresponding "Release.gpg" file).
  • there is no actual real link to the actual distribution of the packages once they have been signed.
    • the delivery (transport method) of the packages can be done in-the-clear, over a network or any off-line mechanism that can be creatively devised
    • the distribution range (mirroring) of the packages is literally unlimited (and unlimitable - even peer-to-peer is possible: see http://www.camrdale.org/apt-p2p/ )
    • the limitless distribution does not impact on security, as long as "security updates" are enabled on a user's device (or otherwise regularly checked: it's a "pull" mechanism, not a "push" mechanism).
  • dynamic package updates can be done, by creating a new URI schema (#New URI proposal (apt:// or yum://))
  • security-blacklisted apps can, under the debian scheme (see #dealing_with_rogue_applications)

List of GNU/Linux Distributions that use Package Signing

At this URL is a useful description of how package signing works in various GNU/Linux distributions. https://wiki.archlinux.org/index.php/Package_signing#How_signing_is_implemented_in_other_distributions

This list excludes BSD ports such as FreeBSD. FreeBSD's system is outlined here: http://www.freebsd.org/doc/handbook/portsnap.html

These systems appear to make prevalent use of SHA1 and MD5 (simultaneously) for extra care on checksums: the use of GPG/PGP is also notably prevalent.

It is worth emphasising that AT NO TIME is there any mention of a GNU/Linux Distribution which makes sole and exclusive use of SSL as the method for distribution of applications.

Package Management: Dependencies (libraries)

Apt and Yum have the capability to store not just applications but also libraries, including version numbers. An application may specify that it is dependent on a particular library including the version number (as a range).

The use of such version control and dependencies will help dramatically cut the duplication of UI libraries which are inevitably going to be deployed, even amongst B2G Team Members let alone application developers.

The context here is that B2G could potentially expand to having 100,000+ applications in stores: devices simply do not have unlimited bandwidth or storage capacity to keep on downloading hundreds of copies, identical or otherwise, of jquery or any other javascript library.

SSL as a host-orientated App Distribution System

SSL is being proposed as a means to distribute applications.

The Problem With Using SSL

SSL is a host-based PKI infrastructure. Thus, it ties everything to hosts. Hosts become the target for attacks; hosts become the weak link; hosts become subject to scalability, which, in the context of a million hits a day from a hundred million mobile phones, instantly highlights that SSL is wildly inappropriate (by contrast, the various well-established and proven GNU/Linux distributions use person-based PKI, based around GPG/PGP).

One problem is that SSL (when used with PKI Certificates for Authentication, aka Certificate 'pinning') is that the solution becomes the problem. When a device may only download from a site over HTTPS where only those devices which have the appropriate public key may connect to that site, then if the app becomes popular then the site will quickly be overwhelmed.

The other problem with relying solely on SSL is that it requires trusting the full set of root certificates on the device. This is obviously not a B2G/OWA specific problem but it does seem to be a little worse in this case, especially in hostile environments when the government has or can easily obtain a root cert. This is why we sign desktop Firefox updates as well as verifying them against a hash downloaded over SSL. Defense in depth.

The third problem can be expressed as "faith in SSL is fairly low". In other words, the difference between HTTP and HTTPS is so small that people may be tempted to just start using HTTP, because setting up SSL and getting a PKI Certificate set up is "too inconvenient".

The fourth problem is that SSL doesn't protect against a Server being compromised. In fact, it would give a false sense of security as the SSL Certificate may have been compromised without the Store's server admin's knowledge (it is a requirement of SSL that the private key be actually stored on the server).

The fifth problem is that, in the case where the private key is distributed widely across multiple hosts in order to spread the load when an app becomes popular, not only must a store have planned in advance to cater for extra demand, but also the wider distribution of the private key makes it more likely that the private key will be compromised.

The sixth problem is that SSL has a processing cost on the establishment of each and every connection, whereas person-based PKI such as that of the debian distribution system requires the package to be digitally-signed once and only once: actually checking the signature is done at the receipient end, and the network infrastructure does not require any actual processing.

The seventh problem is that if a certificate-"pinned" store is down, there is absolutely no way for the applications on it to be made available. period. In the case of contentious applications such as privacy-guarding applications, this actually becomes a serious problem especially in light of the USA's misuse and abuse of power to blatantly disregard other nation's sovereign rights over their citizens' legally-owned domain name by seizing them.

Overall, then, the use of SSL can be clearly shown to fail to meet the requirements, and the primary reason is because SSL PKI is host-based security.

Retrieved from "https://wiki.mozilla.org/index.php?title=Apps/Security/Distribution&oldid=412383"