Comparing two X509Certificate
Hi,
Which is the best way to compare X509Certificates? My system should authenticate users by their certificates and I磀 like to be able to compare the certificate presented by the user and the one - or the info stored about it - in my system.
Using serial number could be a good approach but I must support different CA and I磎 not sure that number is unique among all the CA. Actually, I think it磗 not.
Any idea would be appreciated.
Thanks in advance,
Jorge
# 1
I'm not sure that this makes sense. If your users have to register a certificate with you before they are allowed to access your system then they should be asked to sign a token that you pass to them and then you should verify the signature.
Edit:
Having thought about this I am now certain that it does not make sense since X509 certificates are in effect public keys. Anyone can get hold of anyone's public key/certificate without compromising any security. What matters is that if YOU know someones public key then, as long as they are the only people that know the associated private key, only they can sign which is the only think that proves a person is who they say they are.
Comparison of certificates offers nothing. Since I could get hold of millions of certificates through online directories, if comparison of certificates were all that mattered I could pretend to be any of those millions.
Message was edited by:
sabre150
# 2
Hi sabre150 ,
I see what you mean but there are some cases in which it do make sense. Let磗 say you have an application where users authenticates using a tradicional user/password schema. In that application, users can digitally sign orders but my application need to be sure that the user is not signing any other certificate (at least, that he磗 signing using his own certificate). How would you manage this situation?
Thanks again,
Jorge
# 3
I don't understand. If the user has logged on and then signed an order (using his private key) you will check the signature using his certificate held on file. If it fails then you reject the order.
Once a user has registered a certificate with you (it does not matter whether if is self-signed or veri-signed) you MUST accept any signature that it accepts. The only difference between self-signed and veri-signed is that with self-signed YOU have to verify the identify of your user, not the certificate authority.
Also, I don't see the need for the user to log in other than to identify the certificate in your database that must be used to check the signature on the order. No password is needed for this since the user is not who he says he is he will not have access to the private key so he will not be able to sign the order.
# 4
Hi again,
Let's say I have an corporate application that gives services too some hundreds of users. Not all funtionality requires digital signature, actually, only a little percent of it do. Access to digital signature funtionality is available only to some users (a workflow should be executed first). So I need my users to be authenticate with user/password schema before operating in the system (or creating some kind of different auth page for this module, what it's not a good idea. Too many logins for my users).
Then, I need to be sure the user uses his certificates. It's an extra validation, so to speak (i.e. some users could act with different identities). I wouldn't say it doesn't make sense.
Regards,
Jorge
# 5
> Let's say I have an corporate application that gives
> services too some hundreds of users. Not all
> funtionality requires digital signature, actually,
> only a little percent of it do. Access to digital
> signature funtionality is available only to some
> users (a workflow should be executed first). So I
> need my users to be authenticate with user/password
> schema before operating in the system (or creating
> some kind of different auth page for this module,
> what it's not a good idea. Too many logins for my
> users).
In this situation then it makes sense to use user/password authentication.
>
> Then, I need to be sure the user uses his
> certificates. It's an extra validation, so to speak
> (i.e. some users could act with different
> identities). I wouldn't say it doesn't make sense.
I still think it does not make sense. The user may have obtained a certificate from several Certificate Authorities so do you expect him to remember which certificate to send to you.
In my view, all that matters is that his registered certificate can be used to verify the order. I don't see how comparing two RSA/DSA certificates for equality can add to the security provided. If a hacker has access to the private key needed to sign an order then he surely has access to the publically available certificate associated with that private key.
# 6
If I may add my $.02, Sabre150 has a valid point. A public key, and in extension an X.509 certificate, is supposed to live out in the open. What uniquely identifies a person is the ability to sign arbitrary data using the private key that only she owns, which can be only decrypted by the corresponding public key. If that public key is contained within a certificate with roots to a CA that is considered trustworthy, then you trust that the person who the CA issued the certificate to is the same one that produced the signature.
Mind you, you don't actually need to explicitly sign something. The Client Authentication process of SSL protocol performs this sign-data-verify-signature cycle behind the scenes using a private key and a certificate on the client side and a list of trusted CAs on the server side.
Kind regards,
Anestis
# 7
Let's say one person can access to one of his buddy's computer and using his own user and password can access to the system and use his workmate's private key to sign. The document would be signed by someone that is not the person who logged into the system. This is the situation I'm trying to avoid. It might be too much security, but I wouldn't say it hurts. We're signing really important documents for my company.
Regards,
Jorge
# 8
> Let's say one person can access to one of his buddy's
> computer and using his own user and password can
> access to the system and use his workmate's private
> key to sign.
Then the private key is not adequately protected. Invest in a good key store rather than waste time on this. There is a good free one at http://sourceforge.net/projects/strongkey/ .
> The document would be signed by someone
> that is not the person who logged into the system.
> This is the situation I'm trying to avoid.
I don't see how sending the certificate improves on this because, as I keep saying, the certificate is public to the whole world.
> It might
> be too much security, but I wouldn't say it hurts.
It does not add any security.
> We're signing really important documents for my
> company.
Then even more important to keep the private key safe.
P.S. It is the owner of the private key who is responsible for keeping it safe. If he does not do so then it is not your problem. If his private key signed an order then the owner of the private key deserves everything that happens if he allowed the private key to become public.
Message was edited by:
sabre150
# 9
> P.S. It is the owner of the private key who is
> responsible for keeping it safe. If he does not do so
> then it is not your problem. If his private key
> signed an order then the owner of the private key
> deserves everything that happens if he allowed the
> private key to become public.
You磖e right, it磗 not my responsability. Anyway, if one day I had that problem I磍l call you so you can explain all this responsability stuff to my client, who could have lost thousands of dollars because one of his employees used other磗 private key :-)
I磎 just trying to avoid that situation.
Regards,
Jorge
# 10
> I磎 just trying to avoid that situation.
>
Then use/provide a key safe! Checking the certificate will not avoid that situation.
For a time I worked or a very big credit card company. Their policy was very simple - call in a security expect to check the security architecture then call him in again whenever there was a release. I implemented some of the security but I am no security exert. If the secrets are important to your company then they should call in a security expert to check out your design. If I am wrong and you are right then he will tell you.
P.S. Are you willing to be your career on you being right and me being wrong?
Bye.
Message was edited by:
sabre150
# 11
>
> P.S. Are you willing to be your career on you being
> right and me being wrong?
>
No, absolutely not, I didn't mean to. I was just trying to explain that although you're right - responsability is not mine - things are not always that easy with big clients in business. I'm sure you will agree with me, at least in that point.
# 12
> >
> > P.S. Are you willing to be your career on you
> being
> > right and me being wrong?
> >
>
> No, absolutely not, I didn't mean to. I was just
> trying to explain that although you're right -
> responsability is not mine - things are not always
> that easy with big clients in business. I'm sure you
> will agree with me, at least in that point.
As a Professional the responsibility is yours. If your clients (or employers) are making a mistake then you must bring it to their attention (in writing). If they ignore your advice then be prepared to walk away.
In the final 25 years of my career I walked away just 3 times. In all 3 cases I would do it again because my clients were either being unprofessional (2 cases) or stupid (1 case). I always made sure the clients were aware of why I was walking away.
One of the security consultants I worked with told me that when big companies publicly lose money due to security holes they try to find a scapegoat. He advised that I should take steps to make sure that any blame did not land on me. If YOU do not point out the problems of having no key safe to store the private key then YOU will be prime candidate for scapegoat.
# 13
> Let's say one person can access to one of his buddy's
> computer and using his own user and password can
> access to the system and use his workmate's private
> key to sign. The document would be signed by someone
> that is not the person who logged into the system.
> This is the situation I'm trying to avoid. It might
> be too much security, but I wouldn't say it hurts.
> We're signing really important documents for my
> company.
Jorge,
It is precisely for these reasons, secure digital signature processes do not depend on the signing-key (Private Key of an RSA, DSA or ECDSA key-pair) in a file on the operating system; they are generated and maintained on an external cryptographic token such as a FIPS 140-2 Level 2 or above, smartcard.
When a key-pair is generated on a FIPS 140-2 Level 2 certified smartcard, the Private Key never leaves the card; the message digest of the document to be signed must be sent inside the card to be encrypted (signed). The encrypted hash (digital signature) then comes out of the card to be returned to the calling application to be embedded in a PKCS7 or XML Signature document. When a relying-party needs to verify the digital signature, all they need is the digital certificate of the signer (and the certificate-chain to a trusted CA - even if it is your own internal self-signed CA) to verify the signature. All your application needs is to use either a PKCS11, CAPI or JCE Provider library to communicate with the driver supplied by the smartcard manufacturer (all of them do).
The users who are responsible for digitally signing high-value transactions must be provided with a smartcard and reader of their own. When they want to sign a document, they insert their card into the reader and authenticate to the card with a PIN. When they are finished signing, they remove the card and place it back in their wallet. Now their friend, colleague or any attacker will not be able to use their Private Key to sign anything because the key does NOT exist on the machine.
Smartcards are approximately $100 per person as a kit, and provide the precise protection you are looking for.
