I have a trusted third part A that issues an access token (xml file) to an untrusted client C that uses this token to log into an untrusted server S and access to the authorized files. I want only that C can't manipulate the token changing the permissions stored inside.

I had thought to digitally sign the token with private key of A (RSA digital sign), so that if C changed the token, the signature wouldn't be valid yet and the token rejected from S.

The fact is that I would also like to encrypt the content of the entire token but I can't use the RSA encryption (A encrypts with S public key and S decrypts with his private key) because only A has public/private key while S hasn't.

Indeed, there is no direct network connection beteeen A and S, so If I used a symmetric encryption, how could I get the decryption key to decrypt token?

What kind of en/decryption should I use for this scenario? Thanks

  • 1
    $\begingroup$ What is the reason that S cannot have a key-pair? $\endgroup$
    – Maeher
    Jun 9 '13 at 12:18
  • $\begingroup$ because I don't trust S. I mean if S gives me a self-signed certificate with his public key I don't trust that it is the right one. $\endgroup$
    – user123191
    Jun 9 '13 at 13:01
  • 1
    $\begingroup$ Well, if you do not trust S anyway, then encrypting in any way that enables S to decrypt seems a bit pointless. $\endgroup$
    – Maeher
    Jun 9 '13 at 14:17

Your requirements include the following:

  • S can decrypt the token.
  • C cannot decrypt the token.

Since S must be able to do something that C cannot, it needs to know something that C does not.

Your approach of signing the token with A's signature is fine for ensuring its integrity (C won't be able to modify it) as long as S knows A's public key through a trusted method (e.g. provisioning when you install your application). To encrypt the token, you will need something else.

The most obvious solution is that S generates a key pair and submits the public key to A (in a way that other parties cannot tamper with — TLS would be fine, as S already has A's public key).

A does not need to trust S in any way (unless there is some authorization mechanism and not just anyone can obtain a token, but that would be a different problem which you don't mention in your question). If S submits a self-signed certificate, just accept it, and identify S by its public key. If that certificate is invalid (i.e. S does not know the associated private key after all), then S will not be able to decrypt the token. S already has the power to refuse to decrypt the token, so this attack vector does not have any security impact.

Be careful in your protocol about replay attacks. Depending on what goes into the token, it may be reusable for other purposes, so make sure that all relevant information (identity of S, identity of C, purpose of the token, …) goes into the signature.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.