Smartcard - Uwe Gradenegger

Signing certificates bypassing the certification authority

Time and again in discussions about the security of a certification authority, it comes up that abuse of the certification authority could be contained by its security settings.

However, the fact that the integrity of a certification authority is directly tied to its key material and can therefore also be compromised by it is not obvious at first glance.

one must think of the certification authority software as a kind of management around the key material. For example, the software provides a Online interface for Certificate Enrollment takes care of the authentication of the enrollees, the automated execution of signature operations (issuing certificates and Brevocation lists) and their logging (Certification Authority Database, Audit log, Event log).

However, signature operations require nothing more than the private key of the certification authority. The following example shows how an attacker, given access to the certification authority's private key, can generate and issue certificates without the certification authority software and its security mechanisms being aware of this.

With such a certificate, it would even be possible in the worst case, take over the Active Directory forest undetected.

Use SSH (PuTTY) on Windows with a certificate / smart card

Secure administration of Linux systems includes avoiding SSH logins by password and instead logging in with RSA keys.

The de facto standard for SSH connections on Windows is PuTTY. Here, logon with RSA keys is implemented, but only key files can be used, which has the disadvantage that they are almost unprotected in the file system.

Surely a great option would be to use RSA keys from the Windows world, and perhaps even stored on a physical or virtual smartcard.

Login via smart card using Remote Desktop (RDP) fails with error message "The requested key container does not exist on the smart card."

Assume the following scenario:

A user logs on to a remote desktop system using the smart card logon function.
The user uses a Yubico Yubikey as a smartcard. The required middleware is installed on both the local and the remote system.
The login fails with the following error message:

The system could not log you on. The requested key container does not exist on the smart card.

Use Authentication Mechanism Assurance (AMA) to secure administrative account logins.

Authentication Mechanism Assurance (AMA) is a feature designed to ensure that a user is a member of a security group only if they can be shown to have logged in using a strong authentication method (i.e., a smart card). If the user logs in via username and password instead, he or she will not have access to the requested resources.

Originally intended for access to file servers, however, AMA can also be used (with some restrictions) for administrative logon. Thus, for example, it would be conceivable for a user to be unprivileged when logging in with a username and password, and to have administrative rights when logging in with a certificate.

Signing in via smart card fails with error message "Signing in with a security device isn't supported for your account."

Assume the following scenario:

A user has a Smartcard Logon certificate and logs on to the Active Directory domain with it.
The login fails. The following error message is returned to the user's computer:

Signing in with a security device isn't supported for your account. For more info, contact your administrator.

Associate a universal security group with an Object Identifier (OID) in the Active Directory directory service (Authentication Mechanism Assurance).

Authentication Mechanism Assurance (AMA) provides the ability to tie membership in a security group to enrollment with a smart card certificate containing a specific Object Identifier (OID).

If the user does not log in with the smartcard certificate, but with user name and password, he is also not a member of the security group.

The following describes how to establish the connection between the certificate and the security group.

Configuring a Certificate Template for Authentication Mechanism Assurance (AMA)

Authentication Mechanism Assurance (AMA) provides the ability to tie membership in a security group to enrollment with a smart card certificate containing a specific Object Identifier (OID).

If the user does not log in with the smartcard certificate, but with user name and password, he is also not a member of the security group.

The following describes how to generate a certificate template for use with Authentication Mechanism Assurance.

Creating a virtual smart card in a Hyper-V guest system

For test environments, it is often helpful to be able to work with smartcards. Below is a brief guide on how to set up a virtual smartcard in a Hyper-V guest using a virtualized Trusted Platform Module (TPM).

Domain Controller Certificate Templates and Smartcard Logon

In order for domain controllers to process smart card logins, they need certificates that provide this function.

Editing the NTAuthCertificates object in Active Directory

In the default configuration, all certification authority certificates of Active Directory integrated certification authorities (Enterprise Certification Authority) are located in an object of type CertificationAuthority named NTAuthCertificates within the Configuration Partition of the Active Directory forest.

Domain controller does not check extended key usage on smart card login

Anyone who wants to use the smartcard logon function in their company would be well advised to ensure that their certification authority has the strongest possible security hardening. This includes some essential measures:

Removing all unnecessary certification authority certificates from the NTAuthCertificates object in Active Directory: Each certification authority located in this store is authorized to issue smartcard logon certificates in Active Directory for the complete forest.
Use qualified subordinationRestricting the certification authority certificates so that they are only trusted for the extended key usages actually issued. In the event of a compromise of the certification authority, the damage is then limited to these extended key usages. The "Smart Card Logon" Extended Key Usage would then only be present in the certification authority certificate of the certification authority that actually issues such certificates.

What is interesting about these thoughts, however, is that the domain controllers do not check the extended key usages at all when logging in via smartcard.

Active Directory forest compromised by EDITF_ATTRIBUTESUBJECTALTNAME2 flag

In net circulate unfortunately much at many Instructions (also the big players are not excluded from this, not even Microsoft itself or the Grand Master Komar), which fatally recommends that the EDITF_ATTRIBUTESUBJECTALTNAME2 flag should be set on the certification authority - supposedly to be able to issue Subject Alternative Name (SAN) extension certificates for manually submitted certificate requests.

Unfortunately, this approach is not only unnecessary, it also has some unpleasant side effects, which in the worst case can help an attacker to take over the entire Active Directory forest.

What requirements must be met on the infrastructure side for smartcard logins to be possible?

In order for a smart card login to be successful, some requirements must be met in the Active Directory environment:

Importing a certificate into a smart card

Sometimes it is necessary to import a certificate that uses a software key into a smart card.