My bank proposes certificate. They say I will be able to use it only on one computer. I don't understand: can't I use same certificate on several machines by exporting and reimporting it ?
1
-
Assuming the answer is yes, if one machine is compromised, and you tell the bank to disable that cert, then you will be required to install a new cert, because even the non compromised systems were using the same cert. I don't see that as a problem in your specific case, but I think generally, not specific to banking, this would be the argument against sharing certificates, especially when replacing certs is more expensive or serious. (for example, code signing, or HTTPS)– 700 SoftwareJun 4, 2012 at 22:18
Add a comment
|
3 Answers
Generally speaking, if you can export the private key and import it into another machine then yes you can use it on multiple machines.
This assumes that key is actually exportable, and that the bank isn't doing any other checks that tie the key to a particular computer.
The best thing will to be have the certificates installed in a certified hardware token rather than having it in a soft token implementation. If copies of certificates and key pairs are made possible than it defies the basic principle of having certificate based authentication.
Instead if your bank allows you to have a certificate in a hardware token, than all you need is to have the token inserted in machine of your choice and perform the banking authentication and secure operations like 2FA or transaction signing.
It is important to mentions that having hardware tokens provides higher level of security but at the same time have business implications and reducing user ease as the user might have to install drivers, PKCS#11 dlls or CSP in the systems where the token is needed to be used.
-
1Very true. I would add that the "non-exportable" flag of any certificate is just that, a flag. If it is stored in a software container, getting the key is always feasible.– ixe013Jun 5, 2012 at 16:53
What your bank is saying may have more to do with the certificate application process. I've seen this issue confusing a number of people when working with a institutional CA.
When you apply for a certificate within your browser (e.g. using <keygen/>, CRMF or ActiveX CertEnroll/XEnroll), the browser will generate a key pair during the process and send the public key to the CA as part of the certificate request (the exact format varies depending on the method used).
Later (how long will depend on the CAs out-of-bands verification process), the CA will issue a certificate. Once imported into the browser, this certificate will be associated back with its private key and be visible in your certificate list ('Your Certificates' tab in Firefox, for example).
The problem is that between those two steps (key generation and importing the certificate into the browser), browsers tend not to show anything at all in their user interface. There's usually no entry or list saying "private key waiting for certificate", despite the fact that the private key is there,and the certificate can only be associated back with its matching private key, so this wouldn't work in a different browser.
This can surprise people who've applied with one browser and try to import their new certificate from a different browser once they get the response from the CA at some later date.
Such a statement from your bank may also be a way for them to avoid any explanation regarding how to export certificates altogether. This can easily confuse non-technical users. They may also fear that some users might also use weak passwords to protect their PKCS#12 file (assuming it's the format used for export), which may defeat the point of using certificates.
