You could then use the Yubikey with the x509 certificate to login to you desktop, sign or decrypt emails. These application examples are not topic of this blog post and might be covered in later posts.

You will need a Yubikey 5 and a privacyIDEA installation with version 3.5. We also assume in this example, that you are running Linux on your desktop.

Setup CA in privacyIDEA

First we have to setup a certificate authority (CA), that will sign the certificate signing request (CSR) generated by the Yubikey. privacyIDEA currently only supports local openssl based CAs. This could however be a sub CA to your existing enterprise CA. In this example, we create a new root CA.

Note: You need read access to pi.cfg and write access to /etc/privacyidea/ca

# pi-manage ca create -t local myLocalCA

This pi-manage command will create the CA files and also the CA configuration within privacyIDEA. You are asked a couple of questions and answer them accordingly:

# pi-manage  ca create -t local  myLocalCA

             _                    _______  _______
   ___  ____(_)  _____ _______ __/  _/ _ \/ __/ _ |
  / _ \/ __/ / |/ / _ `/ __/ // // // // / _// __ |
 / .__/_/ /_/|___/\_,_/\__/\_, /___/____/___/_/ |_|
/_/                       /___/

Creating CA connector of type local.
In which directory do you want to create the CA [./ca]: /etc/privacyidea/ca
What should be the keysize of the CA (2048/4096/8192)[4096]: 
How many days should the CA be valid [1800]: 
What is the DN of the CA [/CN=myLocalCA]: 
How many days should the CRL be valid [30]: 
What should be the overlap period of the CRL in days [5]: 
============================================================

        Directory  : /etc/privacyidea/ca
        CA DN      : /CN=myLocalCA
        CA Keysize : 4096
        CA Validity: 1800

        Validity of issued certificates: 365

        CRL validity: 30
        CRL overlap : 5

Is this configuration correct? [y/n] y

You also need to fix the access to the directory

chown privacyidea -R /etc/privacyidea/ca

and create a file /etc/privacyidea/ca/templates.yaml with the contents:

user:
    extenstions: "user"
    days: 365

which will ensure, that the certificate will created as a user certificate with a validity period of 365 days.

You need to do some minor fixtues:

cd /etc/privacyidea/ca
openssl rand -writerand .rnd 
touch index.txt.attr 
chown privacyidea .rnd index.txt.attr

For simplicity comment out two lines (crlDistributionPoints and authorityInformationAccess) in the section “user” in the file /etc/privacyidea/ca/openssl.cnf

[ user ]
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
basicConstraints = CA:FALSE
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
#crlDistributionPoints = @crl_dp_policy
#authorityInfoAccess = caIssuers;URI:http://www.example.com/yourCA.crt

As a last step, go to the Web UI in Config->CA and add the “Certificate template file” /etc/privacyidea/ca/templates.yaml.

Now your CA is ready to go.

Setup PIV trusted certificates

The attestation certificate verifies that the private key was generated on the Yubikey. You can tell privacyIDEA, which attestation certificates should be trusted. Here we will use the Yubikey, so we need to fetch the Yubico PIV CA from their web site.

mkdir /etc/privacyidea/attestation    
wget https://developers.yubico.com/PIV/Introduction/piv-attestation-ca.pem \
     -O /etc/privacyidea/attestation/yubico.pem

The PIV Root CA has signed the attestation CA, that is contained on each Yubikey. We need to retrieve this from the Yubikey. Do do so insert a Yubikey and run the following command:

yubico-piv-tool --action=read-certificate \ 
      --slot=f9 >> /etc/privacyidea/attestation/yubico.pem

The certificate we read from the Yubikey from slot f9 is the attestation CA, that was signed by the Yubico CA. The attestation CA will sign the attestation certificate, that testifies, that the CSR was created on the yubikey. The file yubico.pem now contains the certificate chain of the PIV Root CA and the Attestation CA.

Note: With new production charges Yubico might put a new attestation CA on the yubikeys. So if you buy 100 yubikeys, they will most probably have the same attestation CA, but if you buy another 100 yubikeys several month later, they might have another attestation CA, so you need to repeat this step and put the new certificate chain in a second file.

Configure privacyIDEA policies

privacyIDEA can already enroll x509 certificates. But to ensure, that it will only enroll certificates from CSRs, that are created on the Yubikey, we need to define a new policy, which is available starting with privacyIDEA 3.5.

We create a policy to require an attestation certificate

scope: enrollment
action: certificate_require_attestation=require_and_verify

In this example we will have the administrator enroll yubikeys, so we set an admin policy, that specifies, where the trusted CA chains can be found:

scope: admin
action: certificate_trusted_Attestation_CA_path=/etc/privacyidea/attestation/

Enroll certificate

Now the admin needs to pass the CSR and in addition an attestation certificate, if he wants to have the CSR signed and receive a certificate. The admin could do this manually with the yubico own tools and using the privacyIDEA REST API.

However, in this example we use the privacyidea admin client, which can be found at github.

Note: You can run the command line client on any other computer, it does not need to be your privacyIDEA server.

In this case we are running it on an Ubuntu Linux desktop.

Prepare dependencies:

sudo apt-add-repository ppa:yubico/stable
sudo apt update
sudo apt install yubikey-manager
sudo apt install ykcs11

Create a virtualenv:

virtualenv -p /usr/bin/python3 piv-test

Enter the environment:

source piv-test/bin/activate

Install the privacyidea admin client:

git clone https://github.com/privacyidea/privacyideaadm
cd privacyideaadm
pip install .

Now you can use the current development branch of the admin client in your virtualenv.

Note: You need to have enough hardware access rights, otherwise you might get errors like ” Failed to transmit with protocol T1. Reader is unavailable”

If necessary, you can reset the PIV data on your yubikey:

ykman piv reset

Now you can enroll the yubikey certificate:

privacyidea-enroll-yubikey-piv init-cert -s cornelius -u cornelius \
     -U https://localhost -a super -p test -c myLocalCA -n -P 123456

This will create a CSR on the Yubikey, with the subject “CN=cornelius” and access the Yubikey with the PIN “123456”. The CSR and the attestation certificate will be sent to privacyIDEA at “https://localhost”, the admin will authenticate as user “super” with the password “test” and enroll the certificate to the user “cornelius”. privacyIDEA will verify the attestation certificate, sign the CSR and the certificate will be imported to the Yubikey.

Note: If you have problems enrolling and try to reenroll, you might need to delete temporary files _*.

You can now use the Yubikey with the certificate on it to sign emails or login to your Desktop. As mentioned, this can be a topic for future blog posts.

Conclusion

We showed here how an administrator can enroll a Yubikey with an x509 certificate to a user. At the same time privacyIDEA ensures, that the private key is really generated on the Yubikey. This is an important aspect, when using smartcards for authentication. This ensures, that the private key is unique and can not be copied, neither during the enrollment process nor lateron, making the smartcard a unique authentication factor.

The same way, a user could issue a CSR that was generated on a smartcard to privacyIDEA, making the enrollment process more robust.

This is an important fist step for privacyIDEA to deal with smartcards. We will continue working on smartcard functionalities, smoothening the workflow and enhancing policies.

In an enterprise environment managing x509 certificates and smartcards on a central location is crucial. The Yubikey could contain several certificates. It can contain Webauthn profiles or HOTP slots. If a Yubikey is lost, the service desk should be able to revoke the one hardware key and the central management should know, which certificates and which HOTP slots are affected. With privacyIDEA we are working on this, to ease the life of administrators and service desk users.

This is a cheap way to establish two-factor authentication with something you know and something you have.

Several attack vectors for Two-Factor Authentication with SMS OTP

But lateley there are again some news about the vularability of OTP values sent via SMS. There are different attack vectors. In one scenario the attacker can reroute or “steal” the SIM card by doing social engineering at the telephone provider. In another scenario a malicious software is installed on the smartphone, that can sniff the OTP value.

Yes, privacyIDEA also supports sending OTP values via SMS and privacyIDEA is also vulnarable to these attacks – since it is the basic concept that lacks the necessary security.

Security is shades of grey — or white

But you might have heard that “there is no 100% security”. And that “security is a process”. And now I add to these idioms “Security is Shades of Grey”.

You gain security by using a password on your account to lock the desktop. But are you secure? You gain further security by adding a second factor during authentication. But is your data secure, now? You gain further security by encrypting the harddisk (a.k.a. your data) of your desktop. But is it secure?

Yes, it is good to use a password. You should not use none.

And yes, it is goot to use SMS OTP. It is better than to not use it. In certain cases it might be OK to use SMS OTP being aware of the possible risks.

But there are further steps or other possiblities to increase security.

Choice of Security Level

With privacyIDEA you have the choice, which security level you are going to use. And this may even depend on the application and the client.

You may use SMS OTP, Email OTP, Smartphone Apps like the Google Authenticator, hardware key fobs and seedable tokens like the Yubikey. Using privacyIDEA’s policy definitions, you can define which token type is allowed to be used for authentication at which application. This way you can accept the risk of using e.g. SMS OTP for low security applications and hardware devices like the yubikey for applications requiring higher confidentiality.

See the online documentation on policies for more information or come to the Google Group mailing list.

If you require any professional assistance you may contact the maintainer of privacyIDEA.

Features

Yubico Validation Protocol

Version 2.9 comes with support for the Yubico Validation Protocol. This way you can use common Yubico client like the PAM module for Mac OS. privacyIDEA’s yubico validation protocol can be reached via /ttype/yubikey. For more detailed developer information you may read the module specification.

Questionnaire Token

The questionnaire token lets a user answer a list of questions. The questionnaire token then acts as a challenge response token. After entering the password or OTP PIN, the user is asked an random question, which he needs to answer accordingly.

Paper Token

The paper token lets a user print a list of OTP values, which he can use to authenticate. Internally the paper token is an HOTP token. The printed sheet of paper can be cut and folded and carried in the users wallet.

Enhancements

Besides these new features privacyIDEA 2.9 comes with a list of further enhancements:

• Add Web UI view to display the active challenges.
• The issuer for the Google Authenticator app can be configured.
• The LDAP machine resolver uses an LDAP server pool.
• The LDAP user resolver returns a list of mobile numbers.

Fixes

The following issues have been fixed in privacyIDEA 2.9:

• The test email for the email token now has a sent date.
• Fix problem when using encrypted encryption key.
• Fix upper case problem when logging in to web UI with REMOTE_USER.
• Fix allow set an empty PIN in the web UI.
• Fix import of token file in Web UI.

Download, Install, Upgrade

You can download privacyIDEA from the usual locations. Upgrade is fairly easy, since there are no changes to the database schema from 2.8 -> 2.9.

Please read the installation documentation for further information.

Two factor authentication or multi factor authentication is ment to raise the bar for attackers. They ought to sniff, brute-force or social-engineer your password and in addition steal or “borrow” your hardware token for a “test”.

Still, I wish to think that the Yubikey – being the product of originally a sole Swedish company – has no back doors. So as long as the TISA does not know of side channel attacks or you used a static password with the Yubikey, you might be fine as long as you get the same Yubikey back – undestroyed.

Nevertheless there are additional measures you can take to improve your security with privacyIDEA.

Disclaimer: This will only help, if you are using your hardware token to authenticate to remote systems. If you use your hardware token to unlock let’s say encrypted harddisk of your notebook, you are carrying, this will not help.

Set up privacyIDEA

When you manage your hardware token for remote access with privacyIDEA and you are crossing borders or you are in situations where you

1. think your hardware token could be stolen or otherwise compromised and
2. you do not need the token explicitly (since you are on the plane without internet access)

you might want to call your trusted privacyIDEA administrator (some call it help desk) and have your hardware token locked.

This way the hardware token can not be used to access restricted resources. If TISA is still insisting to get your Yubikey, you can say:

“If you take it, you can keep it”

(No of course you can take it back, but you may see it as compromised and you might need to reenroll it.)

If TISA takes the Yubikey there is not use for them, since the token is locked.

If TISA did not get your Yubikey and you crossed the border, customs or control successfully, you may call your trusted privacyIDEA admin again to reactivate the hardware token.

Conclusion

This might sound a bit complicated but also to simple. But special events like travelling to certain rogue regimes may require special measures.

Thus you have the following authentication factors:

1. SSH Key (soft possession factor – copyable!)
2. optional passphrase on the SSH Key, which is not controlled by the server! (knowledge)
3. OTP token supported by privacyIDEA like Google Authenticator or preferable a Yubikey (hard possession factor – not copyable)
4. an optional OTP PIN controlled by privacyIDEA (knowledge)

Connect SSH to privacyIDEA

Connecting SSH to privacyIDEA is described in this video. It uses the privacyIDEA PAM Module in the online documentation.

In the SSH configuration you need to set

UsePAM yes

This way SSH will authenticate the user against the PAM stack using /etc/pam.d/sshd.

This howto will assume you are using a Ubuntu system. Other systems like CentOS use slightly different PAM configuration, but the idea is the same.

Install privacyIDEA PAM

To use PAM with privacyIDEA you need the privacyIDEA PAM authentication module. On a Ubuntu 14.04 you can install it like

add-apt-repository ppa:privacyidea/privacyidea
apt-get update
apt-get install privacyidea-pam

In other cases you can get it from github with the above mentioned link.

Configure SSH PAM

Now lets take a look at the PAM config for SSH. The file /etc/pam.d/sshd contains a line

@include common-auth

Change this line to

@include common-auth-pi

By creating such a new file it is easier for us to add two factors to every PAM enabled service.

Copy the file /etc/pam.d/common-auth to /etc/pam.d/common-auth-pi. The file /etc/pam.d/common-auth-pi will look like this:

auth     [success=1 default=ignore] pam_python.so /lib/security/privacyidea_pam.py url=https://yourserver \ 
                                                  nosslverify debug
auth    requisite   pam_deny.so
auth    required    pam_permit.so
auth    optional    pam_cap.so

In the file common-auth-pi we replace pam_unix.so with privacyidea_pam. You need to specify the URL of your privacyIDEA server. If everything is working out fine, you can remove the debug parameter. If you have a trusted certificate you can remove nosslverify.

Please assure, that you are logged in to your system or that you have other mean to login like ssh keys. Modifying the PAM stack for SSH can result in not being able to login with a password via SSH anymore.

Now that you have configured

• /etc/ssh/sshd_config
• /etc/pam.d/common-auth-pi
• /etc/pam.d/sshd

you can restart the SSH server for the changes to take effect.

When you now try to login via SSH, the username and password will be sent to privacyIDEA for verification. You can not use you OTP PIN and Yubikey to login.

If you experience any problems, take a look at /var/log/auth.log.

If everything is working fine, you are now authenticating with:

1. OTP token supported by privacyIDEA like Google Authenticator or preferable a Yubikey (hard possession factor – not copyable)
2. an optional OTP PIN controlled by privacyIDEA (knowledge)

Add SSH Keys

You may realize, that if you have an SSH key in the authorized_keys you will not be asked for the OTP. At the moment you either login with SSH key or with OTP. Let’s change this now, that you can use SSH key and OTP.

The current OpenSSH comes with the options AuthenticationMethods. This is used to concatenate required authentication methods. See the man page of sshd_config for more details.

In the file /etc/ssh/sshd_config we add this line:

AuthenticationMethods publickey,password

This means that SSH will require that you pass a trusted SSH key and after this ask you for a password (PIN+OTP), which will be verified by privacyIDEA.

The login will look like this:

root@gawain ~ # ssh root@privacyidea
Authenticated with partial success.
root@privacyidea's password: 
Welcome to Ubuntu 14.04.3 LTS (GNU/Linux 3.13.0-66-generic x86_64)

The “Authenticated with partial success” means, that the authentication with the SSH key succeeded. Now you need to specify the One Time Password to be sent to privacyIDEA.

Note: If you want to login as user “root”, be sure to add “PermitRootLogin yes” to your sshd_config.

Finally we managed to authenticate the users with:

1. SSH Key (soft possession factor – copyable!)
2. optional passphrase on the SSH Key, which is not controlled by the server! (knowledge)
3. OTP token supported by privacyIDEA like Google Authenticator or preferable a Yubikey (hard possession factor – not copyable)
4. an optional OTP PIN controlled by privacyIDEA (knowledge)

Manage SSH Keys with privacyIDEA

Wait! Are you still there? One thing might still strike you:

While all OTP tokens are centrally managed by privacyIDEA, users still put their public SSH keys on all the machines and you are wondering where the SSH keys of all the users are floating around.

There is no easy way for you to revoke a compromized SSH key.

But you can also solve this with privacyIDEA. Users can upload their public SSH keys to privacyIDEA with the tokentype SSH Key.

This way you can also manage all SSH keys in privacyIDEA. In sshd_config you need to use the AuthorizedKeysCommand to retrieve the SSH keys from privayyIDEA just in time. Deleting an SSH key in privacyIDEA will deny access for this user immediatly.

You can read SSH Key Management with privacyIDEA to set this up.

This way you have three strong factors to secure the access to SSH.

The admin client already provided an easy way to enroll a bunch of yubikeys by initializing them one after another. Running

privacyidea -U https://your.PI.server -a admin token yubikey_mass_enroll

you are able to plugin a yubikey, wait for the admin client to initilize it within a second pull it and plug in the next. Without even pressing a key. (Hit Ctrl-C when you are done). This would write all the otpkey material directly to the specified privacyIDEA system. This was the status quo. This way you are able to initialize hundrets of yubikeys just by plugging in and pulling out.

Anyway. In certain cases this would not work, since you might have no USB access on the machine, from which you are accessing the privacyIDEA server.

With privacyIDEA admin client 2.5 it is now possible to initilize a bunch of yubikeys without the privacyIDEA server available. The otpkeys will be written to a file which you can import to privacyIDEA later. Run

privacyidea token yubikey_mass_enroll --filename secrets.csv

and all the secret otp keys will be written to secrets.csv. (Please note, that this file is not encrypted and contains the new secret keys of the initilized yubikeys)

Now you can import the file to any privacyIDEA system.

Cornelius will do a workshop there about installing privacyIDEA, enrolling tokens and authenticating at SSH. You should get an IDEA how easy it is to protect your private data and authenticate with two factors. Especially with a second factor that is totally under your control and not issued to you by any need-to-trust-me “authority” or “vendor”.

Therefor each attendee will get his own Yubikey, which he can initialized so that the cryptographic key material is only know to YOU. And you only.

You can also hear a lightning talk about the concept of locking your desktop with your smartphone but with an additional challenge response mechanism, which is more trustworthy then just a simple bluetooth coupling.

Today I will show you, how you can setup a scenario, where users can authenticate with Yubikey and/or Google Authenticator and you can define centrally, for which server the users need a Yubikey to authenticate and for which other server a Google Authenticator would be sufficient. Thus you can enforce security levels, meaning servers carrying more sensitive data can only be accessed with a hardware device like the Yubikey while others are ok to be accessed with a software token like the Google Authenticator.

Unique user, two tokens, many machines

You should already have read about enrolling yubikeys and how to use privacyIDEA for  two factor authentication to your server farm. So I assume, that you have a running installation.

You should have enrolled two tokens to the user root as depicted below:

The user root has a Google Authenticator (serial OATH…, OTP PIN “google”) and a Yubikey (serial UBOM…, OTP PIN “yubi”) token.

Both tokens can be used to authenticate from all configured clients. From localhost (172.16.200.41):

[root@centos6 ~]# echo "User-Name=root, Password=google977398" | radclient -sx localhost auth testing123
Sending Access-Request of id 167 to 127.0.0.1 port 1812
 User-Name = "root"
 Password = "google977398"
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=167, length=48
 Reply-Message = "privacyIDEA access granted"
Total approved auths: 1
 Total denied auths: 0
 Total lost auths: 0

[root@centos6 ~]# echo "User-Name=root, Password=yubi899739" | radclient -sx localhost auth testing123
Sending Access-Request of id 100 to 127.0.0.1 port 1812
 User-Name = "root"
 Password = "yubi899739"
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=100, length=48
 Reply-Message = "privacyIDEA access granted"
Total approved auths: 1
 Total denied auths: 0
 Total lost auths: 0

Or from a remote host (172.16.200.106):

cornelius@puckel ~ % echo "User-Name=root, Password=google308786" | radclient -sx 172.16.200.41 auth testing123
Sending Access-Request of id 11 to 172.16.200.41 port 1812
    User-Name = "root"
    Password = "google308786"
rad_recv: Access-Accept packet from host 172.16.200.41 port 1812, id=11, length=48
    Reply-Message = "privacyIDEA access granted"

       Total approved auths:  1
       Total denied auths:  0
       Total lost auths:  0

cornelius@puckel ~ % echo "User-Name=root, Password=yubi867011" | radclient -sx 172.16.200.41 auth testing123
Sending Access-Request of id 47 to 172.16.200.41 port 1812
    User-Name = "root"
    Password = "yubi867011"
rad_recv: Access-Accept packet from host 172.16.200.41 port 1812, id=47, length=48
    Reply-Message = "privacyIDEA access granted"

       Total approved auths:  1
       Total denied auths:  0
       Total lost auths:  0

The idea

The idea is to allow access on the machine 172.16.200.106 only with yubikeys. This is the machine that carries tons of sensitive data and we do not want users to authenticate with their Google Authenticator.

The host with the higher security level

To accomplish this privacyIDEA provides a special authorization policy that will only grant access, if the the authentication was performed with the correct token.

So lets configure a policy:

This policy tells the system, that if the client 172.16.200.106 issues an authentication request, it should only be approved, if the serial number of the authenticating token contains the string “UBOM”.

Note: As we are using RADIUS the client 172.16.200.106 issues a radius request to the RADIUS server 172.16.200.41 and the RADIUS server issues the request to the privacyIDEA server 172.16.200.41/127.0.01. Thus the request that arrives at the privacyIDEA server will always be issued by the RADIUS server. So we need to allow the RADIUS server to overwrite the client information – thus the RADIUS server will tell the privacyIDEA server, what the calling RADIUS client was.

We can set this in the system config.

We set the localhost and the eth0 IP of the RADIUS server in a comma seperated list: 127.0.0.1, 172.16.200.41.

The yubikey now can successfully authenticate at the sensitive host:

cornelius@puckel ~ % echo "User-Name=root, Password=yubi773998" | radclient -sx 172.16.200.41 auth testing123
Sending Access-Request of id 88 to 172.16.200.41 port 1812
 User-Name = "root"
 Password = "yubi773998"
rad_recv: Access-Accept packet from host 172.16.200.41 port 1812, id=88, length=48
 Reply-Message = "privacyIDEA access granted"
 Total approved auths: 1
 Total denied auths: 0
 Total lost auths: 0

while the Google Authenticator fails to do so:

cornelius@puckel ~ % echo "User-Name=root, Password=google850707" | radclient -sx 172.16.200.41 auth testing123
Sending Access-Request of id 24 to 172.16.200.41 port 1812
 User-Name = "root"
 Password = "google850707"
rad_recv: Access-Reject packet from host 172.16.200.41 port 1812, id=24, length=55
 Reply-Message = "privacyIDEA server denied access!"
 Total approved auths: 0
 Total denied auths: 1
 Total lost auths: 0

We can see this in the privacyIDEA audit log:

Google Authenticator is still good for default servers

But we can still use the Google Authenticator for the default server with lower security level:

[root@centos6 ~]# echo "User-Name=root, Password=google069728" | radclient -sx 172.16.200.41 auth testing123
Sending Access-Request of id 162 to 172.16.200.41 port 1812
    User-Name = "root"
    Password = "google069728"
rad_recv: Access-Accept packet from host 172.16.200.41 port 1812, id=162, length=48
    Reply-Message = "privacyIDEA access granted"

       Total approved auths:  1
         Total denied auths:  0
           Total lost auths:  0

We can check this in the audit log, again:

Conclusion

privacyIDEA can be used to enroll many different authenticators to your users and mange these devices centrally.

In a second step you can decide who authenticates where with which device without bothering to reenroll any device.

Thus you can enforce your security policies easily. Additionally the audit log keeps track of all events that do not comply to your security policy.