On Jan 30, 2008 9:44 AM, Reinoud Elhorst <[EMAIL PROTECTED]> wrote:
> Just for the exercise, what kind of signing/encryption would be needed here?
> I guess the values (viewerid, ownerid, applicationid) need to be both
> encrypted and signed (where the encryption may actually be used as
> signature).
You at least need signing, you probably want both encryption and
signing. The signing is so a malicious gadget can't tamper with the
security token. The encryption is so you don't leak your internal
user identifiers to gadgets. Encryption alone is not enough to
authenticate the token, you want an HMAC for that. You'll also need
to use different keys for the encryption and the signing. Here's some
pseudocode:
encryptionKey = SHA1("enc" || masterkey)
signingKey = SHA1("sign" || masterkey)
plainText = owner, viewer, gadget, timestamp
IV = 128 random bytes
encryptedToken = AES-128-CBC(encryptionKey, IV, plainText)
signature = HMAC(signingKey, IV || encryptedToken)
securityToken = signature || IV || encryptedToken
You're probably going to want a time limit embedded in the security
token as well. The time limit could be fairly short if you're willing
to use AJAX to have the gadget call back to the container to refresh
the security token every few minutes. If you go with that scheme then
when someone logs out of the container their gadget security tokens
will quickly become invalid as well.
> For the ajax-calls back to the container this is not a problem,
> since a private secret can be used for that in the container. If the gadget
> server needs to be able to do secure phone-home, I guess it will not use
> this #st value, but something else it gets returned from the ajax-calls to
> the container, right?
If the container and the gadget server are run by the same
organization you can use the security token to initiate secure phone
home. The flow would look like this:
- gadget makes a request to the phone home endpoint on the gadget
server (e.g. /jsonp?auth=signed) and includes the security token.
- the gadget server validates the security token and pulls out the
relevant information about the user and gadget.
- the gadget server looks up the appropriate phone home key and signs
the request.
If the container and the gadget server aren't run by the same
organization then this is harder. You would need an IFPC call from
the gadget to the container page, then a request to a phone home
endpoint on the container, then another IFPC call from the container
page back into the gadget to return the data.
Cheers,
Brian
