Private Certification Authorities, SSL and Cisco cert management 1

[silverhairb]

Private Isolated Root / Mutual Authentication SSL

Follows is a short explanation of its mechanism and an example of its deployment.

SSL is a commonly used technique that uses public key cryptography to exchange cryptographic keys used to secure communication over the internet. To work, information is encrypted using the public key contained in digital certificates issued by trusted authorities and operated in a secure manner.

Much has been written on the topic of public key cryptography and its supporting public key infrastructure (PKI). The assumption is that the reader understands the basics of PKI and the mechanisms SSL and most other applications use to authenticate digital certificates.


SSL Certificate Operation and Relevant Options

In a typical SSL session, the client inspects and validates a digital certificate. The database of certificate signing authorities (Certification Authority or CA) is checked to determine whether the CA is in the “trusted CA cache” of the client. If the CA is not listed in the trusted cache, then a validation failure occurs and the client may be asked whether or not to accept the certificate. It stands to reason that if the trusted CA cache contains no entries, every certificate presented will fail validation.

There are several SSL server options of particular interest in this discussion. The first requires mutual authentication. This means that both the server and client must possess and present their digital certificates to the other for validation and for entity authentication. If a client does not have a digital certificate, if the certificate fail validation, or entity authentication fails, then the serer would consider this a mutual authentication failure.

As an extension of mutual authentication failure, the second SSL option is that the session fails on authentication failure. If the client fails authentication then the server ends the session and no further communication takes place.

An organization can establish and operate their own “Private Root Certification Authority” for purposes of issuing SSL certificates to their own users. Issuance may be severely limited to only those with special server access needs.


Sample implementation

Using the above options and a private CA, we can develop the following implementation:

Clear the trusted CA cache in the server. Add the root CA certificate from the organizations private CA.
Issue an SSL server certificate to the server from the organization’s private CA.
Set the SSL options in the server to require mutual authentication and session fail on authentication fail.
Begin issuing certificates from the private CA to only client/users authorized at access the server. Depending on the sensitivity of the data being accessed on the server, protect the private key of the client in a “secure” key storage/cryptographic device such as a smart card.
Install the private root CA certificate in the client’s trusted CA cache.
Only allow only SSL access to the server.

This provides an environment where the server requires the client to present their digital certificate. If the certificate validation process fails on the server, the session fails and the client cannot gain access to the server.


Of interest to this group:

The principles in this "type" of technique (private CA / thin trusted CA cache) were also successfully tested on Cisco router equipment in the late 90s. IIRC, we used Cisco 3604 hardware clients and 36XX routers. At least that's what I think we used. I was testing the techniques, not working with the routers beyond verifying their use of certificates in this scheme.



Background

Necessity is the mother of invention. I developed this technique to address the need for an economical and secure client authentication / access control tool (operating in the background) to bypass the expense and need for manually entering time-sensitive codes from Security Dynamics SecureID tokens. This secure remote access control tool is documented in an informative annex of ANSI X9.49 (Secure Remote Access to Financial Applications). It is currently in use as a secure remote access control tool in the educational and financial industries. I’m not really at liberty to disclose some of the larger users. I didn’t patent this technique since I wasn’t sure whether the design of SSL itself amounted to prior art.

The use of this technique excludes the use of MD5 for purposes of the hashes used in digital signature generation as discussed earlier in this forum.

Anyway, there is it for your information and analysis. In your review and analysis, I welcome attacks and any discovered vulnerabilities.

OK, I’ve had enough adrenaline for the last couple of days.

Time to get back to chemistry. That is, changing wine to urine.

[the other] Bill

 

[maczen]

Bill,
I love this stuff.. LoL

First, I like the use of SSL or even TLS to circumvent MitM attacks as that would seemingly be the most dangerous and obvious vulnerability. This is a good choice so long as MD5 is not utilized, as you stated. The usage of a private CA/RA is also a good choice in this scenario. At least I would think so. Also, from what I have found this system uses RSA just not MD5 with RSA (like the recent hack). I would guess that your system uses SHA-1 with RSA? This sounds like the best option since the SHA-2 family are still somewhat in their infancy and thus untested to an extent but the SHA-2 family is supposed to be the new standard as of 2010.

You said "to bypass the expense and need for manually entering time-sensitive codes from Security Dynamics SecureID tokens". I did a little Googleing and if you are referring to the PIN setup for SecureID then that can actually be disabled in lieu of other security measures (such as password/RSA code combos). Regardless I like the OTP concept as I was looking at Aladin the other day and was admittedly impressed!

The only significant weakness that comes to mind would be the timing that this design relies on for the digital certificates. If an enclosed/internal system is setup for NTP (source) then this would obviously not be susceptible to NTP timing attacks but if external source(s) were used then the system would be open to DoS attacks (but this is also probably obvious). Please remember that I am just getting started with this security stuff... LoL

Please let me know if I am overlooking something!


B Haines
CCNA R&S, ETA FOI

 

[silverhairb]

Not that I can see. There were private key storage issues and some business reasons for different levels of access, but from an operational perspective, you have hit the high points.

PIRMA eliminates MitM attacks since only trusted clients get certificates. If one of them would go bad, then their certificate is revoked. Audit reports make that easy to detect since the identity info in the certificate was forwarded to the application. Only data associated with the identity in the certificate could be accessed.

Recognize that the design of PIRMA dates back to the mid to late 90s. Can't remember the exact year, probably 97 or 98. The application was originally supposed to support authenticated, unattended, automated pick-up of files from a central server. The use of SecureIDs was not really an option in this environment. And I didn't like the Security Dynamics software token since this was high-value financial information.

In terms of attacks, we assessed the risk of DoS attacks against the server and found the use of PIRMA did not increase the risk of the attack. The server was out there anyway, just limited to access via PIRMA. For the [separate] Cisco router application for telecommuters, attacks were not really an issue.

Back when this technique was originally developed, tools like SHA-2 were just an idea we kicked around in the standards working groups. The NSA representatives to the standards groups, typically pretty tight-lipped, were already talking about the need for more hash algorithms back then. All the crypto weenies were worried that SHA-1 would be shown to have problems leaving us with nothing to support all the developing PKI-based systems. The legal weenies were worried that the creation of digital signature laws would be impacted by broken crypto tools creating legal problems. So we were really sticking our neck out on the bleeding edge hoping for the best.

If/when someday you want to dive further into business applications using PKI, ask me about Secure Electronic Transactions (S.E.T.). That's a good place to start.

But that's for another time and thread. Not remotely close to on-topic here.

[the other] Bill

Ending yet another abridged stream of consciousness.

 

[maczen]

Bill,
What is PIRMA? I can't seem to easily locate any info on it.

My understanding, based on your above explanation, is that even if someone managed to block a client who is utilizing this technology after initializing communication with the server but prior to the certificate key changing the MitM would only have access for those 3, 5 or 30 seconds until the key changed (dependent upon configuration)? If that is the case with a decent knowledge of the network topology/OS's etc. and the right software/scripts an attacker would potentially have time to exploit any known vulnerabilities. This is assuming 30 seconds between password changes, most likely inside information and a very skilled attacker (no script kiddie). Is this a feasible issue?

B Haines
CCNA R&S, ETA FOI

 

[maczen]

I am thinking that an attacker would potentially have time to commit a port redirection attack or something similar in thirty seconds (thinking netcat with automated install script), thirty second window, prior knowledge of network and predetermined target. This is more along the lines of crypto techs when they discuss potential weaknesses in hashes. They may locate a vulnerability (SHA-1 in 1996) but admit that the potential to exploit said vulnerability is virtually impossible (yet decide that new algorithms may be needed). I am not saying that this is a feasible attack just wondering if that is a plausible weakness that security personnel may wish to take into consideration.

And shorten the time between password/key changes?

B Haines
CCNA R&S, ETA FOI

 

[silverhairb]

PIRMA is "Private Isolated Root / Mutual Authentication".

I need to think about the attack a little until circumstances of a lower blood alcohol content.

 

[maczen]

Sory, it is getting late and I completely missed that one! LoL Thanks!

B Haines
CCNA R&S, ETA FOI