emmanuel_
asked on
Digital Signature & Identification
Suppose that I have a key pair (Private and Public) to communicate securely via email when it is necessary. Let's assume that someone else one the net e.g. e-shop wants to identify myself as a client using Public Key Cryptography. Do I have a create a different key pair (Private and Public) in order identify myself securely to the e-shop's server?
ASKER
We have two different situations of identification here:
1.myself communicating with the other party via email using Public Key Cryptography. Here we are talking about the past i.e. that a message received at some point in the past did indeed come from the claimed sender (digital signature).
2.myself communicating with an e-shop using Public Key Cryptography. Here we are talking about a live party i.e. I must prove my identification at the point in time when the communication is actually occurring.
e-shop case \\ Challenge response using Public Key Cryptography between myself and the e-shop:
a) The e-shop sends me a nonce (random value) in response to my request to log on.
b) To authenticate myself, I encrypt the nonce with my Private Key, which essentially generates my digital signature.
c) The e-shop compares my response to the original nonce's value, after decrypting it with my Public Key.
Though, it is never a good idea to encrypt something with my Private Key and then send it to somebody else, unless I know exactly what I am encrypting. This is because the encrypted value can be used against me. Only I could have done the encryption on the grounds that only I have the Private Key!
One may suggest the following: OK, you will use (Private1, Public1) keys for communication via email and (Private2, Public2) keys when you want to identify yourself to someone else on-line. So, you will have 2 key pairs, one for digital signature and one for real-time identification. This solution seems to be correct. On the other hand, we know that each and every key pair carries at least the name of its owner. In addition to this, as far as I am concerned, there is no standardized tag on a single key pair, to tell to the outside world ¨Look, this pair is used for digital signing and this for real-time identification¨. This protocol is based on an informal agreement between the two peers i.e. we have agreed to use this key pair when it comes for digital signing and the other one for on-line identification. In conclusion, I don´t think that security must based on such informal agreements between parties. In my humble opinion protocol is not safe and should not be used.
Someone may pretend to identify me on-line. I'll sign something unknown to me (e.g. the hash value of an e-check of $10,000) with my second key pair and then what will I'll tell to the outside world ... ¨Well, look I signed it but with my identification key pair so the check is not valid¨. No one will believe me because there is no way to prove that this key is used for identification and the other for digital signing.
Do you think that this two key pair approach is correct, is it applied in practice?
I'll appreciate any help.
1.myself communicating with the other party via email using Public Key Cryptography. Here we are talking about the past i.e. that a message received at some point in the past did indeed come from the claimed sender (digital signature).
2.myself communicating with an e-shop using Public Key Cryptography. Here we are talking about a live party i.e. I must prove my identification at the point in time when the communication is actually occurring.
e-shop case \\ Challenge response using Public Key Cryptography between myself and the e-shop:
a) The e-shop sends me a nonce (random value) in response to my request to log on.
b) To authenticate myself, I encrypt the nonce with my Private Key, which essentially generates my digital signature.
c) The e-shop compares my response to the original nonce's value, after decrypting it with my Public Key.
Though, it is never a good idea to encrypt something with my Private Key and then send it to somebody else, unless I know exactly what I am encrypting. This is because the encrypted value can be used against me. Only I could have done the encryption on the grounds that only I have the Private Key!
One may suggest the following: OK, you will use (Private1, Public1) keys for communication via email and (Private2, Public2) keys when you want to identify yourself to someone else on-line. So, you will have 2 key pairs, one for digital signature and one for real-time identification. This solution seems to be correct. On the other hand, we know that each and every key pair carries at least the name of its owner. In addition to this, as far as I am concerned, there is no standardized tag on a single key pair, to tell to the outside world ¨Look, this pair is used for digital signing and this for real-time identification¨. This protocol is based on an informal agreement between the two peers i.e. we have agreed to use this key pair when it comes for digital signing and the other one for on-line identification. In conclusion, I don´t think that security must based on such informal agreements between parties. In my humble opinion protocol is not safe and should not be used.
Someone may pretend to identify me on-line. I'll sign something unknown to me (e.g. the hash value of an e-check of $10,000) with my second key pair and then what will I'll tell to the outside world ... ¨Well, look I signed it but with my identification key pair so the check is not valid¨. No one will believe me because there is no way to prove that this key is used for identification and the other for digital signing.
Do you think that this two key pair approach is correct, is it applied in practice?
I'll appreciate any help.
This two pair approach is used in practice.
I worked in a insurrence company that gave each empoyee a encryption key to sign emails and one to sign and encrypt emails.
The 1st key could only be used to sign but not encrypt emails. They were using tctrust PKI:
http://www.trustcenter.de/set_en.htm
Here you can get such a key for private use: http://www.trustcenter.de/products/express/en/en.htm
Tolomir
I worked in a insurrence company that gave each empoyee a encryption key to sign emails and one to sign and encrypt emails.
The 1st key could only be used to sign but not encrypt emails. They were using tctrust PKI:
http://www.trustcenter.de/set_en.htm
Here you can get such a key for private use: http://www.trustcenter.de/products/express/en/en.htm
Tolomir
ASKER
I don't think I am understanding your answer. I haven't mentioned anything about CERTIFICATES (PKI) or ENCRYPTION either. I agree that you may use two key pairs: your PRIVATE key to sign a message and the receiver's PUBLIC key to encrypt the message.
Nope you get 2 pairs of keys (2 private and 2 public keys):
1st belongs to you: the pair for signing emails
2nd belongs to your company: the key pair to encrypt your business emails (the company got a copy of your private key in case something happens to you and you cannot work any longer...)
A PKI is to sign your keys, to make them trustworthy.
So it this way: Give me your full name, I create on e.g. gmail.com an email account, then I create a keypair in your name and upload it to the pgp directory service. Now I send emails signed with that fake private key in your name...
This is where a PKI comes in business: A e.g. TC-Trust Class 2 or 3 certificate is granted after you sent a copy of your ID card to TC-Trust. (Class 3 means you have to show them your ID card, I suppose) then they sign your pair of keys with their class 2 or 3 certificate showing the "world" that this key is legit.
This is the reason I don't really trust a pgp key stored on the directory server. Even if that key is singed by 10 other keys, who says that these are not compromized too.
Tolomir
1st belongs to you: the pair for signing emails
2nd belongs to your company: the key pair to encrypt your business emails (the company got a copy of your private key in case something happens to you and you cannot work any longer...)
A PKI is to sign your keys, to make them trustworthy.
So it this way: Give me your full name, I create on e.g. gmail.com an email account, then I create a keypair in your name and upload it to the pgp directory service. Now I send emails signed with that fake private key in your name...
This is where a PKI comes in business: A e.g. TC-Trust Class 2 or 3 certificate is granted after you sent a copy of your ID card to TC-Trust. (Class 3 means you have to show them your ID card, I suppose) then they sign your pair of keys with their class 2 or 3 certificate showing the "world" that this key is legit.
This is the reason I don't really trust a pgp key stored on the directory server. Even if that key is singed by 10 other keys, who says that these are not compromized too.
Tolomir
ASKER
Who is the SENDER and who is the RECEIVER?
Case 1: If you are the sender and your company is the receiver, it makes sense. When you are away, you SIGN your messages with your PRIVATE key and you ENCRYPT them with your company's PUBLIC key. Only your company can DECRYPT the messages because only they have the PRIVATE key.
Case 2: If you and your company are the sender and somebody else is the receiver, it makes no sense. You SIGN your messages with your PRIVATE key and then ...
>If you ENCRYPT them with your company's PUBLIC key, only you and your company can DECRYPT them because only you have the PRIVATE key.
>If you ENCRYPT them with your company's PRIVATE key, everybody could DECRYPT them on the grounds that everybody knows your company's PUBLIC key.
If someone wants to answer my question please read my >>question<< and >>first comment<<.
Case 1: If you are the sender and your company is the receiver, it makes sense. When you are away, you SIGN your messages with your PRIVATE key and you ENCRYPT them with your company's PUBLIC key. Only your company can DECRYPT the messages because only they have the PRIVATE key.
Case 2: If you and your company are the sender and somebody else is the receiver, it makes no sense. You SIGN your messages with your PRIVATE key and then ...
>If you ENCRYPT them with your company's PUBLIC key, only you and your company can DECRYPT them because only you have the PRIVATE key.
>If you ENCRYPT them with your company's PRIVATE key, everybody could DECRYPT them on the grounds that everybody knows your company's PUBLIC key.
If someone wants to answer my question please read my >>question<< and >>first comment<<.
Hehe. Well almost.
You sign your emails with your private signing key - tell your clients where to find your public signing key.
Now the email is signed but NOT encrypted.
If you got the public key of your client/customer you can encrypt your signed email with their key.
Now your email is signed by you and encrypted, so only your customer can read it.
Your public key is needed if your customer wants to answer you: The customer can sign their email with their private signing key and encrypt it with your public encryption key. (Don't forget, encrypting with your signing key is not possible, so they need not only your signing public key, but also your encryption public key.)
If you go to hospital your company can use your private encryption key to decypher the content and keep the business with your client running, because of key escrow.
That's how secure emails are made: to make sure the recipient get an email really from YOU and no one else claiming to be you AND to make sure the email can only read be the recipient.
Now you might ask: but why are 2 pair of keys needed? Isn't just one key for both: signing and encrypting sufficient? I say NO: The company could use your private key to fake emails in your name. They could ask their mailserver admin to send an email in your name and even leave it in your outbox. How will you prove the compromising email wasn't written and sent by you? So it's very important that you own your signature.
To make sure your identity is correct, the PKI comes in place. It has proven by signing your public keys, that you are indeed the Mr. Smith you claim to be.
The drawback of the who system is, you have to use compatible en- and decryption methods. But if you talk about $10.000 of dollars you can see this as a good investment.
For private use: you can use simple pgp with one pair of keys. Since you gave your friends your public key, there is no need to make certain the messages came from you and no one else, since there is (should) be no one who could claim to be you, because you made no key escrow.
If you communicate with an eshop, right now most use SSL. They claim to be the shop with that name and you can prove it be checking the certificate of the shop. The public key of a trustcenter like verisign is buildin your bowser. So all the browser does is checking if the certificate claiming authenticity is valid.
Right now the shop owner identifies you most likely by checking your creditcard number or by sending you goods to your home adress.
This might be a weakness but it speeds up business.
Hope this helps,
Tolomir
You sign your emails with your private signing key - tell your clients where to find your public signing key.
Now the email is signed but NOT encrypted.
If you got the public key of your client/customer you can encrypt your signed email with their key.
Now your email is signed by you and encrypted, so only your customer can read it.
Your public key is needed if your customer wants to answer you: The customer can sign their email with their private signing key and encrypt it with your public encryption key. (Don't forget, encrypting with your signing key is not possible, so they need not only your signing public key, but also your encryption public key.)
If you go to hospital your company can use your private encryption key to decypher the content and keep the business with your client running, because of key escrow.
That's how secure emails are made: to make sure the recipient get an email really from YOU and no one else claiming to be you AND to make sure the email can only read be the recipient.
Now you might ask: but why are 2 pair of keys needed? Isn't just one key for both: signing and encrypting sufficient? I say NO: The company could use your private key to fake emails in your name. They could ask their mailserver admin to send an email in your name and even leave it in your outbox. How will you prove the compromising email wasn't written and sent by you? So it's very important that you own your signature.
To make sure your identity is correct, the PKI comes in place. It has proven by signing your public keys, that you are indeed the Mr. Smith you claim to be.
The drawback of the who system is, you have to use compatible en- and decryption methods. But if you talk about $10.000 of dollars you can see this as a good investment.
For private use: you can use simple pgp with one pair of keys. Since you gave your friends your public key, there is no need to make certain the messages came from you and no one else, since there is (should) be no one who could claim to be you, because you made no key escrow.
If you communicate with an eshop, right now most use SSL. They claim to be the shop with that name and you can prove it be checking the certificate of the shop. The public key of a trustcenter like verisign is buildin your bowser. So all the browser does is checking if the certificate claiming authenticity is valid.
Right now the shop owner identifies you most likely by checking your creditcard number or by sending you goods to your home adress.
This might be a weakness but it speeds up business.
Hope this helps,
Tolomir
ASKER
My question title is "Digital Signature & Identification" and not "Encryption, Certificates & PKI".
Tolomir> The information you have given is nice written and to the best of my knowledge correct. I admire that you have tried to answer my question but if I give you the points now, IMHO my question will still be unanswered and I will have to ask it again :(
Lets give a last try.
When trying to answer PLEASE take the following ASSUMPTIONS into account:
a) the receiver (e-shop) is SURE about the Public Keys of the sender
b) the protocol used for real-time identification is CHALLENGE RESPONSE (described on my first comment)
c) two keys pairs are used - ONE for digital signing and ONE when it comes for real-time identification
Questions:
1) Is there any option when creating a key pair to DECLARE it as a
- digital signature key pair or
- identification key pair
My answer: NO
Your answer:
2) Can this protocol with the TWO keys be applicable in practice?
My answer: NO, because it is based on an INFORMAL AGREEMENT between the two parties i.e. "we use this key for digital signing and that key for real time identification". Both keys will carry the NAME of the owner and as long as there is NO options to differentiate them (i.e. "this key pair is declared for digital signature use and that for real-time identification") we have a problem.
Your answer:
Tolomir> The information you have given is nice written and to the best of my knowledge correct. I admire that you have tried to answer my question but if I give you the points now, IMHO my question will still be unanswered and I will have to ask it again :(
Lets give a last try.
When trying to answer PLEASE take the following ASSUMPTIONS into account:
a) the receiver (e-shop) is SURE about the Public Keys of the sender
b) the protocol used for real-time identification is CHALLENGE RESPONSE (described on my first comment)
c) two keys pairs are used - ONE for digital signing and ONE when it comes for real-time identification
Questions:
1) Is there any option when creating a key pair to DECLARE it as a
- digital signature key pair or
- identification key pair
My answer: NO
Your answer:
2) Can this protocol with the TWO keys be applicable in practice?
My answer: NO, because it is based on an INFORMAL AGREEMENT between the two parties i.e. "we use this key for digital signing and that key for real time identification". Both keys will carry the NAME of the owner and as long as there is NO options to differentiate them (i.e. "this key pair is declared for digital signature use and that for real-time identification") we have a problem.
Your answer:
Alright, I simply asked tctrust about your questions, because I gave you all knowledge I possess in that field.
I simply translate the answers for you.
> b) the protocol used for real-time identification is CHALLENGE RESPONSE
> two keys pairs are used - ONE for digital signing and ONE when it comes for
> real-time identification
Here we are talking about 2 pair of keys, with different intended purposes:
To sign and to authenticate. These certificate porposes called extentions
are defined by the cetification of the public key by a Certification Authority like TC-trust.
A certificate for a client is usually defined for both purposes.
(**Hier geht es um zwei (!) Schluesselpaare, die unterschiedliche
Zwecke besitzen sollen: Signieren und Authentifizieren. Diese
Zertifikatszwecke, sog. Extensions, werden bei der Zertifizierung
des oeffentlichen Schluessels durch eine CA, z.B. TC, festgelegt.
Ueblicherweise erhalten Clientzertifikate beide Zwecke.**)
> Questions:
> 1) Is there any option when creating a key pair to DECLARE it as a
> - digital signature key pair or
> - identification key pair
There might be cryptographic tools, that create keys and define extentions,
but usually this is done by a CA.
Additional extentions could be SSL or codeSigning.
--->>So the answer is: YES (but task normally done by a CA)
(**Moeglicherweise gibt es Kryptographietools, die Schluessel generieren
und dabei Extensions definieren, aber ueblicherweise macht dies die CA.
Weitere Extensions koennen sein: SSL oder CodeSigning.**)
> 2) Can this protocol with the TWO keys be applicable in practice?
If you really want to use 2 pair of keys, they are definitely different:
each key has it's own number, fingerprint, moduls etc. even if the
distingushed name is the same.
TC-Trust offers keycards, that contain 2 keys with diffrerent purposes of
certification.
--->>So the answer is YES too.
(**Falls tatsaechlich zwei Schluesselpaare verwendet werden, so sind
diese eindeutig verschieden: jeder Schluessel hat seine eigene
Seriennummer, Fingerprint, Modulus, etc., auch wenn der Distinguished
Name derselbe ist. Auch wir stellen Chipkarten aus, die zwei Schluessel
mit unterschiedlichen Zertifikatszwecken beinhalten.**)
---
remarks:
Certificate
A certificate is a public key that has been verified and signed by a Certification Authority. A certificate confirms that a key belongs to the person whose name appears in the subject DN and is therefore often referred to as "electronic ID". The most widely spread certificate formats today are PGP and X.509.
---
Certification Authority (CA)
A Certification Authority is the institution that verifies public keys, thereby issuing digital certificates. This includes the verification of data contained in such certificates, especially the key holder's identity. TC TrustCenter is such a CA.
---
Hope this is information is of use for you.
Tolomir
I simply translate the answers for you.
> b) the protocol used for real-time identification is CHALLENGE RESPONSE
> two keys pairs are used - ONE for digital signing and ONE when it comes for
> real-time identification
Here we are talking about 2 pair of keys, with different intended purposes:
To sign and to authenticate. These certificate porposes called extentions
are defined by the cetification of the public key by a Certification Authority like TC-trust.
A certificate for a client is usually defined for both purposes.
(**Hier geht es um zwei (!) Schluesselpaare, die unterschiedliche
Zwecke besitzen sollen: Signieren und Authentifizieren. Diese
Zertifikatszwecke, sog. Extensions, werden bei der Zertifizierung
des oeffentlichen Schluessels durch eine CA, z.B. TC, festgelegt.
Ueblicherweise erhalten Clientzertifikate beide Zwecke.**)
> Questions:
> 1) Is there any option when creating a key pair to DECLARE it as a
> - digital signature key pair or
> - identification key pair
There might be cryptographic tools, that create keys and define extentions,
but usually this is done by a CA.
Additional extentions could be SSL or codeSigning.
--->>So the answer is: YES (but task normally done by a CA)
(**Moeglicherweise gibt es Kryptographietools, die Schluessel generieren
und dabei Extensions definieren, aber ueblicherweise macht dies die CA.
Weitere Extensions koennen sein: SSL oder CodeSigning.**)
> 2) Can this protocol with the TWO keys be applicable in practice?
If you really want to use 2 pair of keys, they are definitely different:
each key has it's own number, fingerprint, moduls etc. even if the
distingushed name is the same.
TC-Trust offers keycards, that contain 2 keys with diffrerent purposes of
certification.
--->>So the answer is YES too.
(**Falls tatsaechlich zwei Schluesselpaare verwendet werden, so sind
diese eindeutig verschieden: jeder Schluessel hat seine eigene
Seriennummer, Fingerprint, Modulus, etc., auch wenn der Distinguished
Name derselbe ist. Auch wir stellen Chipkarten aus, die zwei Schluessel
mit unterschiedlichen Zertifikatszwecken beinhalten.**)
---
remarks:
Certificate
A certificate is a public key that has been verified and signed by a Certification Authority. A certificate confirms that a key belongs to the person whose name appears in the subject DN and is therefore often referred to as "electronic ID". The most widely spread certificate formats today are PGP and X.509.
---
Certification Authority (CA)
A Certification Authority is the institution that verifies public keys, thereby issuing digital certificates. This includes the verification of data contained in such certificates, especially the key holder's identity. TC TrustCenter is such a CA.
---
Hope this is information is of use for you.
Tolomir
ASKER
>Tolomir: Thank you very much for your prompt reply.
I will form one last question.
General info for the topic:
In version 3 of X.509 certificate format, the extension field was added. This field is used to indicate what particular applications, a particular certificate may be used for.
Examples:
serverAuth = SSL/TLS Web Server Certificate
clientAuth = SSL/TLS Web Client Certificate
CodeSigning = code signing
emailProtection = email protection (signing, encryption, key agreement)
Last question:
Is there any software that enables the U S E R (not the CA) to create keys and define extensions? If there is such a software should we prefer it rather than buying certificates from trusted third parties? Are there any vulnerabilities when using this software?
I will form one last question.
General info for the topic:
In version 3 of X.509 certificate format, the extension field was added. This field is used to indicate what particular applications, a particular certificate may be used for.
Examples:
serverAuth = SSL/TLS Web Server Certificate
clientAuth = SSL/TLS Web Client Certificate
CodeSigning = code signing
emailProtection = email protection (signing, encryption, key agreement)
Last question:
Is there any software that enables the U S E R (not the CA) to create keys and define extensions? If there is such a software should we prefer it rather than buying certificates from trusted third parties? Are there any vulnerabilities when using this software?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Step 2. Homemade certificates.
They only software I have dealt with is openssl. http://www.openssl.org/
The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured, and Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library. The project is managed by a worldwide community of volunteers that use the Internet to communicate, plan, and develop the OpenSSL toolkit and its related documentation.
> I guess this is bulletproof.
Here is a windows version: http://www.slproweb.com/products/Win32OpenSSL.html
The file openssl-0.9.7g.tar.gz\open
is all about extentions:
X509v3 extensions:
X509v3 Basic Constraints:
CA:TRUE
X509v3 Subject Key Identifier:
73:FE:F7:59:A7:E1:26:84:44
X509v3 Authority Key Identifier:
keyid:73:FE:F7:59:A7:E1:26
X509v3 Key Usage:
Certificate Sign, CRL Sign
X509v3 Subject Alternative Name:
email:email@1.address, email:email@2.address
> but there are some constrains:
Display only extensions.
Some extensions are only partially supported and currently are only displayed
but cannot be set. These include private key usage period, CRL number, and
CRL reason.
---
Hope these 2 steps help you well.
Tolomir
They only software I have dealt with is openssl. http://www.openssl.org/
The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured, and Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library. The project is managed by a worldwide community of volunteers that use the Internet to communicate, plan, and develop the OpenSSL toolkit and its related documentation.
> I guess this is bulletproof.
Here is a windows version: http://www.slproweb.com/products/Win32OpenSSL.html
The file openssl-0.9.7g.tar.gz\open
is all about extentions:
X509v3 extensions:
X509v3 Basic Constraints:
CA:TRUE
X509v3 Subject Key Identifier:
73:FE:F7:59:A7:E1:26:84:44
X509v3 Authority Key Identifier:
keyid:73:FE:F7:59:A7:E1:26
X509v3 Key Usage:
Certificate Sign, CRL Sign
X509v3 Subject Alternative Name:
email:email@1.address, email:email@2.address
> but there are some constrains:
Display only extensions.
Some extensions are only partially supported and currently are only displayed
but cannot be set. These include private key usage period, CRL number, and
CRL reason.
---
Hope these 2 steps help you well.
Tolomir
ASKER
Why should someone use seperate key pairs for identification and digital signature?
Quite easy: Your company gives you full access to the digital signature key pair, that has message encryption disabled: it is your property.
Your real encryption/identification key pair belongs to the company instead, you get just a copy of the private key. If you die or are seriously injured/sick whatever, your company is able to decrypt your business mail to be able to complete an open task.
I'm not talking about simple pgp encryption, but certificates from a Certificate Authority: Verisign etc...
Tolomir
Your real encryption/identification key pair belongs to the company instead, you get just a copy of the private key. If you die or are seriously injured/sick whatever, your company is able to decrypt your business mail to be able to complete an open task.
I'm not talking about simple pgp encryption, but certificates from a Certificate Authority: Verisign etc...
Tolomir
Though it would be best to upload that key to a keyserver and point the recepient to that key on the public keyserver.
Tolomir