User:Homunq/Signing service: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
There are many cases when a user might want to sign something. (...examples...) |
There are many cases when a user might want to sign something. (...examples...) |
||
One solution to the above cases would be to have a private key, one per xo, which is used for signing. However, this brings up a problem. Bitfrost assumes that untrusted activities should not be able to impersonate a user. How do we make the signing service secure, in that an activity cannot create unauthorized signatures, without adding UI complexity? |
One solution to the above cases would be to have a private key, one per xo, which is used for signing. However, this brings up a problem. Bitfrost assumes that untrusted activities should not be able to impersonate a user. So the key itself must clearly be held secret by Glucose itself, which should provide a signing service to activities How do we make the signing service secure, in that an activity cannot create unauthorized signatures, without adding UI complexity? |
||
There are, as I see it, three options for security, in rough order from simplest implementation to simplest user experience: |
There are, as I see it, three options for security, in rough order from simplest implementation to simplest user experience: |
||
| Line 9: | Line 9: | ||
2. Bitfrost privilege. In order to make a signature, an activity needs P_IDENT or some similar bitfrost privilege. Essentially, this is like 1, in that a trusted UI path is needed to set the privilege, but it is only one-time. To be truly secure, there must be some way to ensure that the activity is corrupted after the privilege is added. |
2. Bitfrost privilege. In order to make a signature, an activity needs P_IDENT or some similar bitfrost privilege. Essentially, this is like 1, in that a trusted UI path is needed to set the privilege, but it is only one-time. To be truly secure, there must be some way to ensure that the activity is corrupted after the privilege is added. |
||
3. Include in all signatures metadata about the activity that requested the signature. Thus, instead of trusting a user, you trust a combination of |
3. Include, in all signatures that the service provides, signed metadata about the activity that requested the signature. Thus, instead of trusting a user, you trust a combination of [user, specific activity version] or [user, activity signer]. Any metadata about a given activity version (say, a hash) should ideally be confirmable at the moment of including it in a signature. |
||
Latest revision as of 18:06, 5 June 2008
There are many cases when a user might want to sign something. (...examples...)
One solution to the above cases would be to have a private key, one per xo, which is used for signing. However, this brings up a problem. Bitfrost assumes that untrusted activities should not be able to impersonate a user. So the key itself must clearly be held secret by Glucose itself, which should provide a signing service to activities How do we make the signing service secure, in that an activity cannot create unauthorized signatures, without adding UI complexity?
There are, as I see it, three options for security, in rough order from simplest implementation to simplest user experience:
1. Trusted UI path for all signatures. When an activity asks for a signature, Glucose takes over the UI and asks for user confirmation of some kind.
2. Bitfrost privilege. In order to make a signature, an activity needs P_IDENT or some similar bitfrost privilege. Essentially, this is like 1, in that a trusted UI path is needed to set the privilege, but it is only one-time. To be truly secure, there must be some way to ensure that the activity is corrupted after the privilege is added.
3. Include, in all signatures that the service provides, signed metadata about the activity that requested the signature. Thus, instead of trusting a user, you trust a combination of [user, specific activity version] or [user, activity signer]. Any metadata about a given activity version (say, a hash) should ideally be confirmable at the moment of including it in a signature.