Compartir a través de

Non-Repudiation

  • Artículo

Hi Everyone, today I wanted to follow up on my last post about virtualising offline Certificate Authorities. I briefly mentioned non-repudiation and stated it’s a bit more involved than putting a tick in a box on a certificate template. I want to explain my reasoning for this and give you an insight into what might be involved to do this.

For reference, the non-repudiation check box I’m referring to is this one, which you can get to from the extensions tab on a certificate template:

It seems easy enough to provide non-repudiation by simply ticking this box on a certificate template right? Well, no it isn’t, even though it appears on the surface that you have non-repudiation, it’s a little more complicated than that.

What does it all mean?

So what is non-repudiation? The pure definition is as follows:

Nonrepudiation is the assurance that someone cannot deny something. Typically, nonrepudiation refers to the ability to ensure that a party to a contract or a communication cannot deny the authenticity of their signature on a document or the sending of a message that they originated.

What does this mean in terms of PKI then? Essentially what we are saying when we check that box on the certificate template is that the owner of that certificate, when they sign some data, cannot refute the fact that they were the original signer. This is actually quite a big deal and puts a lot of onus on the user and certificate supplier to ensure that these terms can be met.

Why do we need it?

Non-repudiation is more of a legal concept than one which applies to PKI. Therefore, if we want our digital signatures to be able to be held up in a court of law non-repudiation plays a big part in this. Such as within law enforcement if an officer was going to digitally sign a statement. It’s also used for attribution; this can be very important in some circles where the owner of a system needs to be absolutely sure of the authenticity of a message or that we can attribute the origin of the message undoubtedly to the original signer. Ultimately it builds a level of trust with the certificate.

So how do we achieve it then?

Non-repudiation is all about process and procedures, there are some technical controls that need to be in place but mainly it’s down to policy. What we need to ensure is that there is no way that any other entity other than the intended subject of the certificate is able to get a certificate in the subject’s name. For example, if Joe Blogs has a certificate which asserts non-repudiation there should be no way that Jane Blogs should be able to enrol for a certificate that has the subject name of Joe (and is within the same trust hierarchy). If she can then she would be able to sign some data as Joe and therefore non-repudiation is broken. We must also make sure that no one other than Joe can use the private key associated with Joes certificate. For example, if James can somehow gain access to Joe’s key he can sign some data as Joe, again breaking non-repudiation.

The way we do this is all down to the controls we put around our certificate authority and the enrolment processes that we use for the subject. This needs to be absolutely air tight from the Root CA down, such that we can be sure beyond any reasonable doubt that the PKI hasn’t been compromised in any place. If the root is compromised then anything underneath it can be deemed to be compromised and therefore untrustworthy, same from the subordinate CA down. Once that chain of trust is broken so is non-repudiation and the value of the end entity certificates almost becomes worthless.

How do we implement a PKI whereby we can be assured beyond any reasonable doubt that there hasn’t been a compromise, including for the enrolment process of the end entities? The answer is “with great difficulty”, or least with a lot of investment in the security and procedural controls around a PKI which, unfortunately, most organisations don’t want to invest in unless they are a commercial CA or government agency. I won’t go in to excruciating detail on all of the required elements for this but I do want to lay out a framework which needs to be in place.

Certificate Policy and Certificate Practice Statements

First and foremost, and before we build any of the PKI we need to document the technical and procedural controls that we wish to implement in a CP and various CPS documents for our PKI. At a very high level the CP is the document which describes the policies we wish to define in our PKI and contains things such as the enrolment methods which must be used for particular certificate types and how the private keys of the CAs must be protected. For example, we may say that we are issuing high assurance certificates to end entities and their private key must be stored on a smartcard. There can be one or more CP documents in a PKI depending on what policies you wish to apply to your CAs.

The CPS document is associated directly with a CA and describes how a particular CA meets the policy requirements as outlined in the CP. For example, we may say that this CA uses a Hardware Security Module to satisfy the control within the CP which discusses CA private key storage. Generally speaking, each CA that is implemented should have its own CPS as each CA may be managed differently or conform to different policies or elements of a policy.

A policy management board should also exist to ensure internal oversight of the PKI and they should be informed at all stages of implementation and whenever operation of the offline CAs takes place as well as at some instances of operation at the online CAs.

CP’s and CPS’s are also commonly misunderstood within a PKI and how we can build a PKI and associate these policies. I have some thoughts on this I wish to post in the coming weeks as well.

Security Controls Around the CA’s

The security controls of the CA should be documented in the CPS and will include a lot of different elements, I want to touch very briefly on some of the controls you should think about. This is by no means an exhaustive list of all the controls but provides a minimum list of criteria:

Root CA:

  • Should be offline and never connected to any network. This is to ensure that no network based attack can be undertaken or malicious actor can connect to the CA. With it being offline we can be assured that only people with physical access to the CA can log on and perform operations at it, therefore limiting its attack surface. This is why I think virtualised offline CAs are a bad idea.

  • The CA should be protected with sufficient physical security controls. Typically, this means in a restricted datacentre, with nominal controls such as a protected building, high fences, security guard, CCTV, authentication to the server room (biometric or access card) and finally a secured rack or room where only authorised people have access.

  • Only authorised people should have physical and logical access to the CA. These people should be nominated teams or individuals within the organisation who have some authority. For example, the head of IT and the information security manager. It is good practice to implement dual person control such that both these people or their representatives need to be present at the same time to access the CA both physically and logically. Think about this as they show in the movies when launching a nuclear missile, two people of authority need to be present with their keys and insert and turn them at the same time. This stops one person having ultimate control of the asset meaning more than one person needs to be coerced for a compromise. This obviously needs to be implemented such that there is redundancy in the access control, if only two people have access and one goes on holiday then you lose operational access to the CA. The organisation needs to define the roles and responsibilities for the CA access. In terms of logical access control, a good method is to have a long complex administrator password to the root CA and split this into two halves, say 12 characters each and then each representative has one half of this password. It would also be prudent to encrypt the local hard drive of the CA to stop offline attacks to the server.

  • The CA’s private key should be protected and stored in a Hardware Security Module. There are some very important reasons for this. Firstly, the HSM device provides a very robust environment where the key is stored, in a tamper evident and in some instances tamper resistant piece of hardware. The key is only ever in plain text within the confines of the HSM and cannot be extracted and ex-filtrated from the box. All signing operations are done within the secure hardware. The HSM provides a hardware based random number generator that provides excellent entropy for key generation and also accelerates signing operations because this is all done using a dedicated crypto-processor. Lastly, the HSM provides excellent access control mechanisms for key operations, such as requiring k of n people to load and operate the private key. This means that out of a total of n people k people are required to perform the operation, so we can set this to say 3 of 5 people. Again this limits collusion between people and means many people will need to be coerced to compromise the integrity of the CA.

  • The CA should be implemented following scripted and robustly documented procedures in the format of a key signing ceremony. Unfortunately, this does not include party poppers and hats but is instead a very strictly controlled procedure which is usually audited by a third party. The third party audit gives oversight to the implementation and ensures the organisation follows the exact procedure they have defined in the documentation and this isn’t deviated from. Some of the roles within a key signing ceremony are as follows:

    • Auditor / Key Ceremony Observer – responsible for third party oversight

    • Key Ceremony Directory – responsible for the overall security of the ceremony

    • Policy Management Board Representative – this person is responsible to the policy management board and reports the progress and status of the PKI implementation or operation

    • Key Component Holder – there will be many key component holders and they are responsible for the secure retention and usage of the key component during the ceremony. For example, this may be a HSM card or passphrase that is used. The k of n principle is enforced by these people

    • Key Component Courier – these people are responsible for the secure transportation of the key components before and after the ceremony. The components should be stored in tamper evident containers, for example police evidence bags.

    • Key Component Custodian – these people are responsible for the secure storage of the various key components and the signing in and out of the component to the courier.

    • CA Operator – this person is the technical operator of the CA and performs the actual role installation and technical tasks according to the documentation.

If you’re really interested in key singing ceremonies check out this video https://www.youtube.com/watch?v=b9j-sfP9GUU which was recorded to demonstrate the controls and procedures that were put in place for the signing of the Root DNS zones for DNSSEC. The concepts in the video are entirely applicable to a PKI key signing ceremony.

As you can see the process and procedures of the installation of the CA far outweigh the technical elements of performing the role installation in server manager. The above only touch on the main points of the CA security, it can be far more intricate than this and requires a lot of documentation and patience to do it right!

The online CAs will have similar controls, such as the HSM, physical access controls and implementation ceremony. However, as the CA is fully online, i.e. network connected, it will require extra security controls around its logical security posture. A hardened build should be used, with the firewall enabled and network security controls in place. Also, the administration of the CA should be limited to only the required administrators and a robust Privileged Identity Management practice should be in place (check out MIM 20126 and Windows Server 2016 for this). The CA is a tier 0 system and therefore good credential hygiene should be in place and security management practice for this and the underlying AD should be conforming to the current recommended practice. See the following whitepapers for help on this:

By managing your PKI and other core infrastructure systems to these high standards we can be sure, beyond reasonable doubt, that a compromise of the infrastructure is very, very, unlikely. It isn’t impossible but the bar is raised significantly.

Enrolment Strategy

Once you have a well-managed, securely implemented and operated PKI you need to be able to get some certificates from it for your end entities. This could be for things like encryption services, authentication and crucially digital signature with non-repudiation. What good is a PKI if it can’t issue certs? The actual enrolment process for end entity certificates needs to be as robust as the PKI controls we have spoken about. Auto-enrolment does not cut it for non-repudiation, we need to have a verification process for our subjects that usually involves the four eyes principle, i.e. two people, one to create the request and one to approve it. How can we place any value in the end entity certificates if the only verification for the subject is a letter from their mum? Let’s look at some of the controls we need to put in place:

  • The subject’s identity must be verified using some form of physical ID. In the UK we have a standard for identity checks to government systems called e-Gif Level 3. This normally requires the presentation of two forms of ID, nominally a driving license and passport. Therefore, when the subject enrols for their certificate the identity information in it is as good as the ID presented, in this case two forms of government issued ID.

  • Sponsorship is another must. We can’t let anyone enrol for a certificate from the PKI. We need to ensure that the subject is authorised to enrol, we can do this by ensuring they have sponsorship from their manager, business owner or other person in authority.

  • I mentioned the four eyes approach. This provides split responsibility for the enrolment of the certificate, again ensuring collusion of two or more people is necessary to subvert the security controls of the CA. This can be done by having one person or role which is responsible for the ID verification of the user and the generation of the request and another role or user who is responsible for the actual issuance of the certificate. The enrolee should be present during the request creation and during the issuance to ensure that only the subject of the certificate receives the certificate from the CA.

  • Only the subject of the certificate should ever be in control of the private key associated with the certificate. This is ultimately achieved using a smartcard. A smartcard is absolutely necessary for non-repudiation and they keys must be generated on card. The principle of a smartcard is identical to the principle of a HSM. The smartcard has its own crypto-processor and storage area for the key material and is deemed to be secure as the key cannot be extracted from the card (yes there are some side channel attacks on smartcards but they are the most secure key storage we have for users). If the key is in software stored on a Windows machine, then any administrator of that machine can export that private key and then you break non-repudiation and the trust of that certificate. It is also essential that the private key is generated on the card and never backed up. We need to be certain that only the owner of the smartcard is ever in control of the private key and that it is never present anywhere else or observed by any other person or system.

Summary

Can we say we have non-repudiation by putting a check in a box on a certificate template? Absolutely not, we must first jump through many hoops to be sure that only the owner of a private key associated with the certificate ever has access to it. This involves many controls, policies, procedures and security practices, some of which are listed above. Is this article the definitive list for everything you must do to secure a PKI, absolutely not, but hopefully it gives you some insight into what you need to do to implement a robust PKI. If implemented correctly we get non-repudiation but also the trust and assurance we place in all certificates has a higher value and we can have very strong two-factor authentication to internal systems.

A good friend of mine Andy Lyon has a brilliant quote I’m going to steal as I think it is apt for this post:

“CAs are easy, PKI is hard”

Comments

  • Anonymous
    October 16, 2015
    A Snippet
  • Anonymous
    July 07, 2016
    Thx friend ;)