Solved

CMS and keys

Posted on 2014-04-14
9
359 Views
Last Modified: 2014-04-21
My understanding is that CMS is a form of pkcs#7, and encapsulates a certificate but not a private key

and it is used in MIME messages

So  if it is used in mail, messages, etc, wouldnt you need a private key, and since CMS does not contain a private key, would taht be a problem

What am I missing

Thanks
0
Comment
Question by:Anthony Lucia
  • 5
  • 4
9 Comments
 
LVL 28

Accepted Solution

by:
becraig earned 250 total points
ID: 39999949
Ok so I think you are missing a very important thing here
probably due to the language used from time to time)

A "Certificate" can contain BOTH a public and private key, or a public key only, it is still a "certificate" in either instance.

For SMIME certs you encrypt for sending with the private key and users encrypt messages to you with the public portion of the key.

The word "certificate" wraps all of this, you have a certificate on your end with both private and public, the other person has a certificate on their end with only public.



Are the answers unclear on any of the previous questions ?

I noticed they are all still open, so not sure if you need more info on them.
0
 
LVL 33

Assisted Solution

by:Dave Howe
Dave Howe earned 250 total points
ID: 40000042
you are missing usage cases.

CMS/PKCS#7 is a container format - it contains digitally signed data.

the data *can be* a certificate (in which case it is a bunch of descriptive data, a date range, and a public key, all digitally signed by a private key) or it *can be* a message - all digitally signed by a private key). In the latter case, usually the certificate that matches the private key is sent as well - this isn't required, strictly, but makes life more convenient in a lot of cases.

the private key is never sent, nor is it needed - if the signed message is received, then all that is needed to verify the signature is the public key (and the certificate has that, or at least a reference to that)

if the message is also encrypted, then it is encrypted to the recipient's public key, as found in a certificate created by them - the sender never has the private key, so clearly could not include it in the CMS "bundle".

if you are using it purely for a certificate, then you can consider it as being like a pfx file that *lacks* a private key.
0
 
LVL 28

Expert Comment

by:becraig
ID: 40000073
Ok Dave I am not sure what how what I said was inaccurate  ?

I stated SMIME / CMS utilizes a private key.


Can you explain to me if my understanding below is incorrect:
How Does S/MIME Work?

Encrypting, signing, and decrypting S/MIME email messages requires the use of certificates. Certificates are simply public and/or private keys wrapped up in a specific format, so that they can be used together and understood by various programs.


An S/MIME email message can be signed, encrypted, or both. Encrypting a message is done using the public key certificate of the recipient of the message. This ensures that only the recipient can decrypt the message, as the encryption is done so that only the recipient's private key certificate can reverse the encryption. Signing the message is done with the sender's private key certificate, and ensures to the recipient that the sender of the message is who they say they are. A hash of the message is also created by the signing process so that the recipient of the message knows that the message has not been changed since it was written
0
 
LVL 33

Expert Comment

by:Dave Howe
ID: 40000129
@becraig: a certificate NEVER contains a private key. that's the main one. but itemized...

Encrypting, signing, and decrypting S/MIME email messages requires the use of certificates.
No. encryption or signature verification requires a public key. decryption or signing requires a private key.

Certificates are simply public and/or private keys wrapped up in a specific format, so that they can be used together and understood by various programs.
no. certificates are a series of data items (usually an asserted identity, usage flags, validity date range and signing entity name, plus a public key) signed by a private key. if the private key matches the public key, then the certificate is "self signed". the private key is never contained in the certificate, and the public key is part of a bundle of data items that together allow you to associate the public key with an identity and validate that assertion.

An S/MIME email message can be signed, encrypted, or both.
Correct :)

Encrypting a message is done using the public key certificate of the recipient of the message.
Encrypting the message is done with a public key, which is usually found in a certificate. Actually, that isn't true either; the message is actually encrypted with a randomly generated key, and THAT key is encrypted with the public key, but the first association is close enough. If there is more than one recipient, the random key is encrypted multiple times (once per recipient) and stored in the same CMS file.

This ensures that only the recipient can decrypt the message, as the encryption is done so that only the recipient's private key certificate can reverse the encryption
Close enough, except that there is no such thing as a "private key certificate". Private keys are just private keys.

Signing the message is done with the sender's private key certificate, and ensures to the recipient that the sender of the message is who they say they are. A hash of the message is also created by the signing process so that the recipient of the message knows that the message has not been changed since it was written
Reasonably close. the message is hashed, and the hash of the message is encrypted with the private key, then that encrypted hash is stored in the CMS along with the certificate that contains the public key. On receipt, a recipient can re-calculate the hash, decrypt (with the public key extracted from the certificate) the original hash, and compare the two. That ensures that only someone with the private key could have encrypted that hash, and that the hash matches (hence, the message has not been altered in transit)

The certificate identifies the asserted identity of the signer, by virtue of the hashes matching (after the public key is used to decrypt the stored hash) and the other info contained in the certificate - in order to know that the signer was in fact who they said they were, the validity of the certificate must then be checked.
0
IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

 
LVL 28

Expert Comment

by:becraig
ID: 40000168
I am not sure where I wrote that a PRIVATE KEY was a certificate, I have re-read twenty times what I wrote and CANNOT find it  ?

I am not sure where you got the ASSUMPTION that an assertion was made that a private key was a certificate ??

Reasonably close. the message is hashed, and the hash of the message is encrypted with the private key,
I am not sure how saying the hash of the message is encrypted using the private key (being a bit more granular is different to saying the message is encrypted using the private key ??)

If I read what you wrote correctly you are agreeing with what I wrote, but adding a layer ?
How does that invalidate what I wrote or provide any clarity to the Author's question ?

You also stated
the private key is never sent, nor is it needed
While I acknowledge I never indicated the private key was ever sent, I am not sure how you arrive at the conclusion a private key is not needed in a key-pair  ?

My answer for clarity and simplicity to the author was:
1)  The term certificate can be used to indicate the public key portion or public key + private key indicated in a previous answer to the author RE: pkcs 12 format.

2) As for the second question:
So  if it is used in mail, messages, etc, wouldn't you need a private key, and since CMS does not contain a private key, would that be a problem?


Reasonably close. the message is hashed, and the hash of the message is encrypted with the private key, then that encrypted hash is stored in the CMS along with the certificate that contains the public key. On receipt, a recipient can re-calculate the hash, decrypt (with the public key extracted from the certificate) the original hash, and compare the two. That ensures that only someone with the private key could have encrypted that hash, and that the hash matches (hence, the message has not been altered in transit)

I think we are both in agreement  on the responses provided ?
0
 
LVL 33

Expert Comment

by:Dave Howe
ID: 40000264
@becraig:
I am not sure where I wrote that a PRIVATE KEY was a certificate, I have re-read twenty times what I wrote and CANNOT find it  ?
I am not sure where you got the ASSUMPTION that an assertion was made that a private key was a certificate ??


Odd then. In one reading, I find:

A "Certificate" can contain BOTH a public and private key, or a public key only, it is still a "certificate" in either instance.
Certificates are simply public and/or private keys wrapped up in a specific format
only the recipient's private key certificate can reverse the encryption
Signing the message is done with the sender's private key certificate,

took me significantly less than 20 tries there :)

I am not sure how saying the hash of the message is encrypted using the private key (being a bit more granular is different to saying the message is encrypted using the private key ??)
Hence "reasonably close". However, that the hash of the message (and not the message itself) is encrypted is important; nobody ever encrypts a message directly with a PKI keypair - it isn't done. Instead, you encrypt either a randomly generated key (for encryption) or a hash (for signatures).

While I acknowledge I never indicated the private key was ever sent, I am not sure how you arrive at the conclusion a private key is not needed in a key-pair  ?
The private key of the sender is not only never needed by the recipient, it must never be *sent* to the recipient - the entire system relies on the private key being kept private.

1)  The term certificate can be used to indicate the public key portion or public key + private key indicated in a previous answer to the author RE: pkcs 12 format.
No, it can't. It is very important not to confuse a certificate (which is a distinct entity) with a pkcs#12 or #7 CONTAINER (which can contain many certificates, and in the former case, also a private key) or indeed private/public keys themselves.  Each are distinct entities and concepts, and not understanding which can be nested inside which other(s) can lead to significant confusion.

So  if it is used in mail, messages, etc, wouldn't you need a private key, and since CMS does not contain a private key, would that be a problem?
Essentially, the private key must be kept private by its owner. It will be used appropriately by its owner on construction or consumption of a CMS container, but the private key is not needed to encrypt to a recipient, or verify a signature on receipt.

A CMS message container therefore does not need and should not contain a private key - correspondingly, a pkcs#7 certificate-only container does not and cannot contain a private key, hence can be used only to verify a signature or create an encrypted message, not decrypt or sign.

I think we are both in agreement  on the responses provided ?
Probably. I think you know in general the concepts, even if you seem a bit hazy on the names of things :)
0
 
LVL 28

Expert Comment

by:becraig
ID: 40000315
LOL your responses highlight why I gave the answers I did to avoid excess confusion.

You continue here to INSIST I said a private key was a certificate
(I still cannot read anywhere in my initial response where that "assignment" was made.)

As for the quotes on SMIME those were simply provided from a published source simply  for the purpose of providing clarity on the concept of encryption/decryption, where you insisted there was no private key involved in SMIME encryption.
the private key is never sent, nor is it needed
I think I may have taken your comment above out of context in reading that NO private key is ever needed in SMIME encryption.

As for "sending" the private key I know there is no way in the world I could ever make that suggestion :)


I had previously made it clear to the author CMS was a container type pkcs7 as indicated there was no private key contained in CMS hence his statement:
My understanding is that CMS is a form of pkcs#7, and encapsulates a certificate but not a private key.

So at this point there was no thought nor belief by the author based on my previous response that there was a private key in a CMS container.



Thanks for the additional clarification  :)
0
 
LVL 33

Expert Comment

by:Dave Howe
ID: 40000397
You continue here to INSIST I said a private key was a certificate
(I still cannot read anywhere in my initial response where that "assignment" was made.)


And in response, I pointed out two instances where you used the exact phrase "private key certificate", and two where you said a certificate could contain a private key.

now, given I never once asserted that you said that a private key WAS a certificate, that was enough to illustrate what I *DID* say, which is this:
a certificate NEVER contains a private key
and
there is no such thing as a "private key certificate". Private keys are just private keys.

Now, if there is some specific statement of mine that isn't addressed by the above four quotes, feel free to point it out and I will clarify :)

I think I may have taken your comment above out of context in reading that NO private key is ever needed in SMIME encryption.
 I was obviously not sufficiently clear - the private key is not sent nor needed to be sent - so for that I apologise - at least this discussion should make that point more clear to the OP.

So at this point there was no thought nor belief by the author based on my previous response that there was a private key in a CMS container.
And yet, your statements, such as
The term certificate can be used to indicate the public key portion or public key + private key indicated in a previous answer to the author RE: pkcs 12 format.
Could have led to erroneous beliefs - which I would rather the OP did not adopt, given he appears to be trying to learn the entire field of PKI, secure transmission, and application proxying one EE question at a time :)
0
 
LVL 28

Expert Comment

by:becraig
ID: 40000426
Thanks a lot Dave, as I indicated the SMIME portion was a copy paste from a publication (laziness on my part) so the inclusion of the word "certificate" was not my doing  :(


That being said, having been in the industry for a while a lot of people tend to lump everything together (Where containers are concerned), hence me saying to the OP
"due to the language used from time to time".

I am sure you have had the same experience as myself of having people referring to the container format as the certificate, this was an attempt to disambiguate the OP in the event during his learning he came across that specific instance.

As far as identifying the fact that these were in fact just containers and the the concept is key pairing a private and public key, I think that had already been established.

I do appreciate your input though, I think our discussion on this has provided as clear a picture as one could possibly expect as far as a crash course on key infrastructure  and digital certs...


Gotta love EE :)
0

Featured Post

How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

Join & Write a Comment

Suggested Solutions

Article by: btan
Provide an easy one stop to quickly get the relevant information on common asked question on Ransomware in Expert Exchange.
It’s a strangely common occurrence that when you send someone their login details for a system, they can’t get in. This article will help you understand why it happens, and what you can do about it.
Sending a Secure fax is easy with eFax Corporate (http://www.enterprise.efax.com). First, Just open a new email message.  In the To field, type your recipient's fax number @efaxsend.com. You can even send a secure international fax — just include t…
This video shows how to remove a single email address from the Outlook 2010 Auto Suggestion memory. NOTE: For Outlook 2016 and 2013 perform the exact same steps. Open a new email: Click the New email button in Outlook. Start typing the address: …

705 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

20 Experts available now in Live!

Get 1:1 Help Now