Hi
I've been thinking about the benefits of signing and trusted
applications. Much of what we have been interested in are
applications that talk to others over the network. In this
case the interesting thing would be to be able to prove that
the other end of the communication is who it is: our application,
and not just somebody else implementing the same protocol.
This could be easily done if the platform provided a function
like:
SignWithPlatformPrivateKey( salt, claim_this_is_application_X) -> signature
This API would only work if you are calling it from application_X,
or alternatively
SignWithPlatformPrivateKey( salt,
claim_this_is_from_vendor_with_ACS_id_X) -> signature
The public part of the platform key would be available to anybody,
and claim_this_is_application_X would have a known form,
so anybody could verify in an interactive protocol that the application
is who it claims to be.
The platform key would have to reside on the device and would thus
be vulnerable to attacks. It could either reside in a tamper-proof
bit of hardware, or there could be a highish number of those keys
(even one per IMEI), with a service that would give you the public
key based on an identifier (since we already assume the existence
of a network connection). The communication with the service could
be verified with traditional PKI, like SSL. In this case the API
would look like
SignWithPrivateKey(salt, claim) -> signature, identifier_of_keypair
Is there anything like this in the plans?
Cheers,
Mika Raento
"Mika Raento" <[email protected]> wrote in message
news:4k3gfMyfGHA.1896@extapps30...
> Hi
>
> I've been thinking about the benefits of signing and trusted
> applications. Much of what we have been interested in are
> applications that talk to others over the network. In this
> case the interesting thing would be to be able to prove that
> the other end of the communication is who it is: our application,
> and not just somebody else implementing the same protocol.
>
> This could be easily done if the platform provided a function
> like:
> SignWithPlatformPrivateKey( salt, claim_this_is_application_X) ->
> signature
> This API would only work if you are calling it from application_X,
> or alternatively
> SignWithPlatformPrivateKey( salt,
> claim_this_is_from_vendor_with_ACS_id_X) -> signature
>
> The public part of the platform key would be available to anybody,
> and claim_this_is_application_X would have a known form,
> so anybody could verify in an interactive protocol that the application
> is who it claims to be.
>
> The platform key would have to reside on the device and would thus
> be vulnerable to attacks. It could either reside in a tamper-proof
> bit of hardware, or there could be a highish number of those keys
> (even one per IMEI), with a service that would give you the public
> key based on an identifier (since we already assume the existence
> of a network connection). The communication with the service could
> be verified with traditional PKI, like SSL. In this case the API
> would look like
> SignWithPrivateKey(salt, claim) -> signature, identifier_of_keypair
>
> Is there anything like this in the plans?
It sounds very expensive, especially if need a high number of keys. Which
will make it a solution for expensive (== enterprise) apps. To me it looks
like you can implement this in the app itself.
--
Sander van der Wal
www.mBrainSoftware.com
Sander van der Wal wrote:
>
> It sounds very expensive, especially if need a high number of keys. Which
> will make it a solution for expensive (== enterprise) apps. To me it looks
> like you can implement this in the app itself.
>
How? I don't see any way of proving the identity of my application to
a third party outside the phone that somebody couldn't fake.
Mika
"Mika Raento" <[email protected]> wrote in message
news:8tF9ie$fGHA.1044@extapps30...
> Sander van der Wal wrote:[color=green]
>>
>> It sounds very expensive, especially if need a high number of keys. Which
>> will make it a solution for expensive (== enterprise) apps. To me it
>> looks like you can implement this in the app itself.
>>
>
> How? I don't see any way of proving the identity of my application to
> a third party outside the phone that somebody couldn't fake.[/color]
You app has a public and a private key. It signs messages with it's private
key, and other apps can decode your app's messages with your app's public
key.
--
Sander van der Wal
www.mBrainSoftware.com
Sander van der Wal wrote:
> "Mika Raento" <[email protected]> wrote in message
> news:8tF9ie$fGHA.1044@extapps30...[color=green]
>> Sander van der Wal wrote:[color=darkred]
>>> It sounds very expensive, especially if need a high number of keys. Which
>>> will make it a solution for expensive (== enterprise) apps. To me it
>>> looks like you can implement this in the app itself.
>>>
>> How? I don't see any way of proving the identity of my application to
>> a third party outside the phone that somebody couldn't fake.[/color]
>
> You app has a public and a private key. It signs messages with it's private
> key, and other apps can decode your app's messages with your app's public
> key.
>[/color]
Yes, but the private key isn't actually secret, since anybody with the
SIS can extract it, right?
Hmm, is SIS files could be encrypted with a public key where the private
key was only available on the device, that would solve the same thing,
right?
Mika
"Mika Raento" <[email protected]> wrote in message
news:%238RBGBBgGHA.2324@extapps30...
> Sander van der Wal wrote:[color=green]
>> "Mika Raento" <[email protected]> wrote in message
>> news:8tF9ie$fGHA.1044@extapps30...[color=darkred]
>>> Sander van der Wal wrote:
>>>> It sounds very expensive, especially if need a high number of keys.
>>>> Which will make it a solution for expensive (== enterprise) apps. To me
>>>> it looks like you can implement this in the app itself.
>>>>
>>> How? I don't see any way of proving the identity of my application to
>>> a third party outside the phone that somebody couldn't fake.
>>
>> You app has a public and a private key. It signs messages with it's
>> private key, and other apps can decode your app's messages with your
>> app's public key.
>>[/color]
> Yes, but the private key isn't actually secret, since anybody with the SIS
> can extract it, right?[/color]
You can send the private key after the program has been registered.
> Hmm, is SIS files could be encrypted with a public key where the private
> key was only available on the device, that would solve the same thing,
> right?
Yes.
--
Sander van der Wal
www.mBrainSoftware.com
>>>[color=green]
>> Yes, but the private key isn't actually secret, since anybody with the SIS
>> can extract it, right?
>
> You can send the private key after the program has been registered.[/color]
But it doesn't solve anything. If I use just one key, any user can
compromise the proof. If I use one per device, that device can still be
mimiced by an attacker, since there's no way to prove the IMEI to
outsiders either.
Mika
"Mika Raento" <[email protected]> wrote in message
news:xYFMFSMgGHA.2496@extapps30...[color=green][color=darkred]
>>>>
>>> Yes, but the private key isn't actually secret, since anybody with the
>>> SIS can extract it, right?
>>
>> You can send the private key after the program has been registered.[/color]
>
> But it doesn't solve anything. If I use just one key, any user can
> compromise the proof. If I use one per device, that device can still be
> mimiced by an attacker, since there's no way to prove the IMEI to
> outsiders either.[/color]
Let's talk economics before engeneering. How much mony is there for doing
the verifiication process for each transaction? In other words, how much are
you prepared to spend to protect that transaction? And how much do you think
an attacker is prepared to spend on attacking your protection?
--
Sander van der Wal
www.mBrainSoftware.com