EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Question concerning certificates

Also by EldoS: Callback File System
Create virtual file systems and disks, expose and manage remote data as if they were files on the local disk.
#12470
Posted: 02/17/2010 14:54:25
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Hi,
in my preliminary tests with certificates I was using the provided cert.pfx, loaded it using LoadFromStreamPFX. Now I'm having to deal with an enrollment server, wich provides certificates in binary DER format (.CER) (?). What options do I have to provide my client and server with this certificate(s)?

Regards
#12471
Posted: 02/17/2010 15:54:58
by Ken Ivanov (EldoS Corp.)

Enroll works in the following way (simplified):
1) A party generates a keypair locally. Then it puts the private key to the system certificate store, while sending the public key to the enrollment server using so-called certificate request.
2) Enrollment server generates a certificate using the public key contained in the request and sends it back to the requesting party.

The private key generated in such way is usually not extractable from the system. That is, to be able to use such certificate for private operations (signing, authentication etc.) you have to access the key via the means provided by the system. SBB includes TElWinCertStorage component that allows to access certificates contained in the system stores. A common location for personal certificates is MY system store.

Basically, you have to do the following to make your server (or client) use enrolled certificate:
1) Get the certificate using TElWinCertStorage object,
2) Add it to a separate TElMemoryCertStorage object,
3) Assign the latter to the CertStorage property of the needed component (TElSecureServer or TElSecureClient).
#12472
Posted: 02/17/2010 16:09:02
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Thanks. I admit, there are lots of questions open, sorry...
1) By help of which tools can I generate a keypair?
2) Why is the system store incorporated here?
3) What do I have to do whith the certificate, returned by the enrollment server? Seems, it has to be passed to the storage again, if it has to be retrieved from the storage in step 1)
3) Does SBB have tools to digitally sign messages?

Sorry, seems I don't know too much about all this...
#12473
Posted: 02/18/2010 00:24:51
by Ken Ivanov (EldoS Corp.)

Quote
1) By help of which tools can I generate a keypair?

You can generate keypairs with many tools, including MMC and SBB-driven ones.

Quote
2) Why is the system store incorporated here?

Hmm, that is how I understood your question. You said that the server provides certificates in DER format, while mentioning nothing about private key generation. That's why I concluded that the keypair is generated transparently to you, and this only can be done if it is performed by Windows XEnroll.

So I have to correct myself: the system store is only involved if the keypair is generated by Windows (in particular, using XEnroll). If the keypair is generated by some other software that saves private key to file, no system store is needed.

Quote
3) What do I have to do whith the certificate, returned by the enrollment server? Seems, it has to be passed to the storage again, if it has to be retrieved from the storage in step 1)

The public copy of the certificate (DER) should be sent to all the parties you are communicating with (i.e. the ones that would need to authenticate you).

From the technical point of view, to authenticate yourself you need to pass certificate with corresponding private key to the appropriate object (particularly, TElDTLSClient or TElDTLSServer). In case of PFX (both certificate and private key are contained in the same file) you only had to load the PFX into the TElX509Certificate instance. If the private key is contained in an individual file, it should be loaded into TElX509Certificate object with one of the LoadKeyFromStreamXXX() methods after the public certificate has been loaded there.

If the private key is contained in Windows system store (and thus cannot be extracted and passed to the component directly), you will have to import the generated certificate to the store as well. However, as far as I remember, XEnroll imports it automatically for you.

Quote
3) Does SBB have tools to digitally sign messages?

Yes. What exactly standard (PKCS#1, PKCS#7, other) do you need to be conformant to?
#12474
Posted: 02/18/2010 01:28:55
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Quote

You can generate keypairs with many tools, including MMC and SBB-driven ones.

Even openssl? If SBB: Any samples available?

Concerning the other issues: I would like to resume this discussion, once I have a more clear picture of it all. Currently I'm a gorilla in the fog, that's too dangerous.

Thanks for clarifications nevertheless.

Regards
#12475
Posted: 02/18/2010 01:39:24
by Ken Ivanov (EldoS Corp.)

Quote
Even openssl? If SBB: Any samples available?

Yes, and OpenSSL too.

Please take a look at the following samples:
1) CertDemo generates certificates, i.e. the keypair and the corresponding certificate are generated at the same time.
2) CertReqDemo generates keypairs and the corresponding certificate requests. Certificate request is supposed to be sent to the CA, which will issue a certificate basing on the information contained in it.
#12476
Posted: 02/18/2010 04:43:38
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

OK, I've now created a self-signed certificate, which should be OK for my purposes (RELOAD stack, see http://tools.ietf.org/html/draft-ietf-p2psip-base-07). The cert is in the store and Windows claims I have a private key for it. I could manage to export public and private key to a PFX file, which should be consumable by the SBB TElSecureServer/Client storage properties.

But I have to meet some RELOAD specials:
Quote

10.3.1. Self-Generated Credentials

If the "self-signed-permitted" element is present and set to "TRUE",
then a node MUST generate its own self-signed certificate to join the
overlay. The self-signed certificate MAY contain any user name of
the users choice.

The Node-ID MUST be computed by applying the digest specified in the
self-signed-permitted element to the DER representation of the user's
public key (more specifically the subjectPublicKeyInfo) and taking
the high order bits. When accepting a self-signed certificate, nodes
MUST check that the Node-ID and public keys match. This prevents
Node-ID theft


Q1: Concerning 10.3 of the draft
Quote
A single name this user is allowed to use in the overlay, using
type rfc822Name.

I suppose, the "rfc822Name" element may be used to provide a username. How can I set this element using SBB in order to generate a self-signed certificate?

Q2: The second topic in the 10.3.1
Quote

The Node-ID MUST be computed by applying the digest specified in the
self-signed-permitted element to the DER representation of the user's
public key (more specifically the subjectPublicKeyInfo) and taking
the high order bits.
is something, I have to do at runtime, once I have loaded the certificate. How to access this special element?

Concerning your question
Quote
Yes. What exactly standard (PKCS#1, PKCS#7, other) do you need to be conformant to?


I summarize, what I've found so far in the draft
Quote
12.2
In addition, messages and data are digitally
signed with the sender's private key, providing end-to-end security
for communications.


And concerning 5.3.4
Quote

struct {
SignatureAndHashAlgorithm algorithm;
SignerIdentity identity;
opaque signature_value<0..2^16-1>;
} Signature;

it seems to be a matter of my definition (algorithm).


Many thanks in advance
#12477
Posted: 02/18/2010 05:20:44
by Ken Ivanov (EldoS Corp.)

Quote
I suppose, the "rfc822Name" element may be used to provide a username. How can I set this element using SBB in order to generate a self-signed certificate?

This element can be set via the subject alternative name extension prior to generation:
Code
Cert.Extensions.Included = Cert.Extensions.Included | SBX509Ext.Unit.ceSubjectAlternativeName;
Cert.Extensions.SubjectAlternativeName.Content.Add();
Cert.Extensions.SubjectAlternativeName.Content.get_Names(0).NameType = SBX509Ext.Unit.gnRFC822Name;
Cert.Extensions.SubjectAlternativeName.Content.get_Names(0).RFC822Name = "<the needed name>";


Quote
Q2: The second topic in the 10.3.1
...
is something, I have to do at runtime, once I have loaded the certificate. How to access this special element?

The value of subjectPublicKeyInfo structure can be obtained with the use of TElX509Certificate.GetPublicKeyBlob() method.

Regarding message signing -- though the specification does not specify the exact standard to use for signing, I assume it to be PKCS#1. TElRSAPublicKeyCrypto class provides all the necessary functionality for creation and validation of PKCS#1 signatures.
#12478
Posted: 02/18/2010 05:38:53
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Cool, looks good (the rfc822 thing)
Quote

Regarding message signing -- though the specification does not specify the exact standard to use for signing, I assume it to be PKCS#1.

I agree, they are not very specific. How do you come to your assumption?

RELOAD states
Quote
algorithm
The signature algorithm in use. The algorithm definitions are
found in the IANA TLS SignatureAlgorithm Registry.


But in the IANA docs I don't find something usefull:

Quote
Registry Name: TLS SignatureAlgorithm Registry
Reference: [RFC5246]
Range Registration Procedures
------- ------------------------
0-63 Standards Action
64-223 Specification Required
224-255 Reserved for Private Use

Registry:
Value Description Reference
------- ---------------------------- ---------
0 anonymous [RFC5246]
1 rsa [RFC5246]
2 dsa [RFC5246]
3 ecdsa [RFC5246]
4-223 Unassigned
224-255 Reserved for Private Use [RFC5246]



UPDATE: Had a quick look into RFC5246. Seems, you're right. Is this, where your assumption comes from?

Regards
#12479
Posted: 02/18/2010 06:03:10
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Quote
This element can be set via the subject alternative name extension prior to generation:
Code

Cert.Extensions.Included = Cert.Extensions.Included | SBX509Ext.Unit.ceSubjectAlternativeName;
Cert.Extensions.SubjectAlternativeName.Content.Add();
Cert.Extensions.SubjectAlternativeName.Content.get_Names(0).NameType = SBX509Ext.Unit.gnRFC822Name;
Cert.Extensions.SubjectAlternativeName.Content.get_Names(0).RFC822Name = "<the needed name>";


Hmm. Having difficulties to figure out, what the right place is to insert this code into your certdemo...
Also by EldoS: Callback File System
Create virtual file systems and disks, expose and manage remote data as if they were files on the local disk.

Reply

Statistics

Topic viewed 3496 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!