ubuntu-phone team mailing list archive

[Bob Looter <xreuze@xxxxxxxxx>]

Hi Everyone,

I think we can do this a simple way. Since it is a developer that first has
to validate with cert key's when up-loading apps to the store or to the
server has to validate with a signature that the app is holding canonical
standards and quality .  What the end user or a mobile operator does in
case wanting to add own app's with out uploading to store or shared server.
In those cases we might run in to problems. We might have to add in a
element that checks a validation cert key between parent and child since
Mobile device is always a child device. In a initial handshake checks for a
validation key is present. It will resolve many problems in my opinion. I
know when i worked in Nokia and we used Symbian which is Windows based.
Where RSA keys is checked in the register. I am sure in handshake mode with
other networks we need the validation key to present so our phones can talk
in larger networks.

but is this validation not done by the SIM which belongs to ISP provider
already. ?

I think we do not worry about this since i am sure that SIM or ISP does
this validation.


On Wed, Jun 18, 2014 at 4:27 PM, Ondrej Kubik <ondrej.kubik@xxxxxxxxxxxxx>
wrote:

> On Fri, Jun 13, 2014 at 6:29 PM, Martin Albisetti <argentina@xxxxxxxxx>
> wrote:
>
>> On Fri, Jun 13, 2014 at 12:54 PM, Ondrej Kubik
>> <ondrej.kubik@xxxxxxxxxxxxx> wrote:
>> >>
>> >> All the client cares about is that our signature is valid. It doesn't
>> >> matter what the developer does. Devices will not check developer's
>> >> signatures. We can make sure our servers are aware of the transition
>> >> and handle it appropriately.
>> >
>> >
>> > I believe idea is to make signature check on device side before
>> installing
>> > click, otherwise if we leave check only on server and device installs
>> > anything what comes form server we still have some problem, and it will
>> not
>> > resolve side loading issue.
>> > So I think there is still problem. If we sign all the "unattended"
>> > applications with default key, and then developer decides to update
>> such an
>> > application and sign it with own key, this should be refused by the
>> device,
>> > otherwise there is hole in the security model. Or am I missing
>> something?
>>
>> Yes, it will check signatures before installing. What I think you're
>> not understanding is that it's the server signature, not the developer
>> signature.
>> There are 3 actors in this scenario, Developer, Store and Device.
>> 1) The Developer creates a package, signs it and uploads it to the Store.
>> 2) The Store validates that signature, and signs the signature (plus
>> other metadata).
>> 3) The device gets the file, validates the server signature, ignores
>> the Developer signature.
>>
>> The Device only trusts and validates the Store. The Store validates
>> the Developer. This model lets us change how we validate Developers
>> over time.
>> So in the current scenario -and this is speculation until we actually
>> start doing any of the work- we'd one day sign all current packages,
>> that we have no developer signature, grandfathering existing binaries
>> as validated.
>> At some point in time (which doesn't have to match up with this first
>> step) we start requiring developers to sign their packages. This will
>> increase the Store's confidence that the binary it has came from the
>> developer and was not tampered with in the middle. We currently fully
>> rely on SSL and OpenID authentication, which is ok but could be
>> better, which is why we'd add signing.
>>
>> The developer can change their keys 3 times a day if they want,
>> devices don't care because they don't validate them. The server does.
>>
>> For side loading, all bets are off. If you sideload, you need to know
>> exactly what you're doing. You either turn off validation all
>> together, or you add another key to validate and are responsible for
>> the whole chain not being tampered with.
>>
> Yeah, but then this is not solving problem I have described in initial
>  email here.
> Idea is to protect from using side load to update existing application
> with intruder's version to gain access to application private data or
> phone's resources.
> If developer mode is something easy to enable, which should be given the
> spirit of Ubuntu, it'd easy way in.
> We can elaborate on user data wipe as part of the side-loading enablement,
> but that seems like harsh measure.
> Also I believe even phone with enabled side loading should still be
> secure, which won't be the case.
>
>>
>>
>> >> > Are we planning to have policy in places allowing apps to share
>> package
>> >> > only
>> >> > if they have same signature?
>> >> >
>> >> > If two different apps are coming from same developer and share same
>> >> > package
>> >> > name ( and same signature) will they share same sandbox or will they
>> be
>> >> > able
>> >> > to peak into each other's sandbox, at least data wise?
>> >>
>> >> We don't have anything in mind yet, and I don't think we'd do it based
>> >> on signatures, but I'll defer that to the security team when the time
>> >> comes.
>> >> Developers get a namespace when they sign up, I'd expect that
>> >> namespace to determine this relationship, rather than signatures.
>> >
>> > Sorry for term confusion.
>> > Multiple application with same namespace on one device could come only
>> > signed with one same signature.
>> > Yes sandbox boundaries should be determined by namespace. Ideally two
>> apps
>> > in same namespace should be able to share private data.
>>
>> Well, no. As explained above, multiple applications under the same
>> namespace can have different Developer signatures.
>> For clarity, a namespace is "ar.com.beuno", I own that, nobody can
>> publish under that except me (enforced by the Store). I can have 2
>> apps, "ar.com.beuno.app1" and "ar.com.beuno.app2", which have their
>> own unique identifier within the same namespace.
>> As Rodney points out, our current security model would stop any
>> sharing of data, we can revise this in the future but nothing
>> currently indicates that we should (and instead have everything go
>> through "trusted helpers").
>>
>> Hope this makes more sense!
>>
>>
>> --
>> Martin
>>
>
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp
>
>