[higgins-dev] Re: Question about ICardProtocolHandler code (Token decryp

[David Campos <noymn.the.archangel@xxxxxxxxx>]

I see... Finally I understood the meaning of the "AppliesTo" param :)

Thanks for resolving my doubt Sergey. Anyway, since that line is not into a conditional sentence, Higgins IdP always have to send an encrypted token to Higgins RP, otherwise that line of code would fail saying that the token can't be decrypted, wouldn't it?

I haven't tested it, it's all guesswork, but, if I remember well, somebody had recently problems with that line and his problem was that he was doing a non-SSL authentication. I remember that somebody said that Sample-RP was only expecting SSL-authentications (so probably encrypted tokens). Could you confirm me if the following scenarios are right?

P-Card Auth ---> though SSL ---> encrypted token by CardSelector
P-Card Auth ---> no SSL ---> encrypted token by CardSelector
M-Card Auth with appliesTo ---> though SSL ---> encrypted token by IdP

M-Card Auth with appliesTo  ---> no SSL ---> encrypted token by IdP
M-Card Auth without appliesTo ---> though SSL ---> clear token

M-Card Auth without appliesTo  ---> no SSL ---> clear token

Am I right? Thanks for your help,
---
David Campos
Safelayer Secure Communications S.L.
DMAG UPC Researcher

On Thu, Sep 3, 2009 at 12:42, Sergey Lyakhov <slyakhov@xxxxxxxxxxxxxx> wrote:

David,

 

> My question is... when is the token ciphered? Who ciphers it? CardSpace?

> I don't think that the IdP is able to cipher the token after generation, mainly because there should not

> be any direct interaction between IdP and RP so IdP is unable to get RP public key.

 

In case of p-card, token is encrypted by selector.

In case of m-card, selector may send RP certificate to IdP as part of AppliesTo information in RST message. So, IdP encrypts a token if AppliesTo contains a certificate.

 

Thanks,
Sergey Lyakhov

----- Original Message -----

From: David Campos

To: Sergey Lyakhov

Cc: Higgins (Trust Framework) Project developer discussions

Sent: Wednesday, September 02, 2009 5:11 PM

Subject: Question about ICardProtocolHandler code (Token decryption)

Hi Sergey,

I have been looking though your RP code in order to find where the token is verified and claims are extracted. I've found that the token first is decrypted with a private key (obtained through the keystore) and afterwards verified.

My question is... when is the token ciphered? Who ciphers it? CardSpace?

I don't think that the IdP is able to cipher the token after generation, mainly because there should not be any direct interaction between IdP and RP so IdP is unable to get RP public key. The only solution that comes to my mind is that CardSpace recieves a clear token through an SSL channel and afterwards it ciphers it with the RP SSL public key, but this scenario does not seem really logical to me since the comunication is always covered with the SSL layer.

Could you please enlight me about what is decrypted and why in the following instruction?

  log.info("Decrypt token using key " + key + " key algorithm " + key.getAlgorithm());
  ie = secext.DecryptElement(elemToken, (PrivateKey)(keyStore.getKey(keyStoreAlias,keyStorePwd.toCharArray())));
  log.info("Decrypted token looks like\n"+ie.getAs(java.lang.String.class));

If it does help you, is the line 146 of ICardProtocolHandler that is found inside org.eclipse.higgins.rp.icard package.

Thank you for the help.

Regards,

---

David Campos

Safelayer Secure Communications S.L.

DMAG UPC Researcher