yubikey: Configuración y uso de infraestructura OTP

Introducción:

Las llaves de hardware o tokens, se utilizan para implementar niveles de autenticación de dos factores. Algo que sabes, el password como el primer factor, y algo que tienes que sería una llave Yubikey configurada con tu usuario.

El nivel de seguridad es igual de alto que el token RSA, a final de cuentas, al única diferencia práctica es que el token, te da un numero que hay que copiar, único y diferente sincronizado con la cuenta por medio de "algún algoritmo mágico" y la llave Yubikey, en vez de mostrarlo en pantalla, lo "escribe", por que al final la llave Yubikey es detectado como teclado y por eso es compatible con cualquier plataforma que reciba usb, windows, linux, mac... 

Que es lo que escribe el Yubikey, depende de una serie de parametros, una llave aes y eso es precisamente lo que vamos trataré de documentar aquí.

Yubikey 

Las llaves yubikey, son llaves que general One Time Password u OTP por sus siglas en ingles, cada vez que uno activa la llave, esta genera un número de identificación diferente. Es exactamente igual a cuando se usa un "token" bancario. Se hace algo para generar un resultado, lo normal es picar un boton para que nos de una secuencia de números que más vale que copiemos. Yubico ofrece el mecanismo para implementar toda la cadena de autenticación que es como sigue:

Se tiene un cliente que hace uso de un server de autenticación que consulta algunas cosas de el almacén de las llaves, obviamente toda la infraestructura debe de estar coordinada. 

KSM o Key Storage Manager. 

Pero lo primero que se tienen es una base de datos llamada la keystorage, para lo que en términos de seguridad es nuestro KSM o Key Storage Manager. 

El KSM, como todo lo de seguridad suena muy "acá", pero en realidad, no es más que una base de datos y una tabla para fines prácticos. Para fines teóricos de seguridad y de implementación, el KSM es la párte más importante y débil de nuestra infraestructura de llaves, es en donde vamos a almacenar las llaves AES que se almacenan en los equipos yubikey, lo cual nos permite desencriptar la información que contiene la yubikey. 

El KSM debería de ser una base de datos hiper-vigilada, hiper-autditada, por el lo que acabamos de comentar, pero seamos honestos, nadie lo hará, pero para mitigar esto, mi recomendación sería que la pusieran en un servidor con su propia base de datos y sin acceso más que a ciertas direcciones ip y usuarios, ademas de su hardening normal. 

La estructura de la KSM es:

Como se puede observar, es bastante sencilla.

Segun la documentación para generar llaves AES, como nunca debes de guardar "sin encriptar la informacion" lo pasa por el pipe y la firma con un dato, pero para fines de que saber que diantres esta  haciendo, nos podemos saltar esa parte.

Cuando ejecutamos el comando pasando el numero de la llave o el ragno de las llaves que queremos generar la salida es:

 perl ykksm-gen-keys.pl  1 

# serialnr,identity,internaluid,aeskey,lockpw,created,accessed[,progflags]

1,cccccccccccb,3f7a64615f3c,5ce3fb71c78292397678a556b1c0be02,4bbbe24a0335,2013-03-03T19:27:32,

Como podemos ver, casi se mapea 1-1  la información a la tabla, donde corresponde:

Campo Tabla	Campo Comando	Switch	Valor
serialnr	serialnr	Copia de la yubikey	1
publicname	identity	-ofixed=	cccccccccccb
created	created	n/a	2013-03-03T19:27:32
internalname	internaluid	-ouid=	3f7a64615f3c
aeskey	aeskey	-a	5ce3fb71c78292397678a556b1c0be02
lockcode	lockpw	-c	4bbbe24a0335
creator	n/a	n/a	n/a
active	n/a	n/a	n/a
hardware	n/a	n/a	n/a

Ahora una explicación de los campos:

1. serialnr creo que no necesita explicación, es el numero de serie.
2. publicname es la parte no encriptada que se configura en la llave OTP para su envio.
3. created la fecha de creacion de la llave.
4. internalname es el valor que se usa en el uid de la llave OTP y viaja encriptada.
5. aeskey es la llave aes utilizada para la encriptacion por parte del otp.
6. lockcode es el password colocado en la llave para proteger la configuración.
7. creator quien crea la llave
8. active si la llave esta activa
9. hardware ni idea, supongo que si es un OTP de hardware o puede ser de software.

Ahora, volviendo a la documentación, se tiene un "archivo encriptado" donde vienen la serie de estas llaves AES generadas, hay que notar que mucha de la información, pues, no tiene mucha relación con nada, continuando con la misma documentación ahora se importa este archivo a la base de datos con el comando ykksm-import.pl

Si nos fijamos, lo  único que hace realmente el comando es tomar esta información, desencriptarla con la llave que usamos para encriptarla y si no le pasamos el parametro --creator, pues entoces pone de llave de encriptacion en el creador, active y hardware estan como default 1.

Así que para fines prácticos, nos podemos obviar este proceso y subirlos a mano o con algún otro método que definamos y modificar la estructura de la base de datos, para por ejemplo que el dato de creator pueda contener algo más significativo que 8 caracters. Estas herramientas vienen en el paquete http://code.google.com/p/yubikey-ksm/ que es solamente la parte de almacenamiento del servidor de autenticación.

Yo supongo que ya tienes el servidor de autenticación configurado y el cliente, y lo que realmente falta es saber que datos ponerle a la llave, por lo menos eso es lo que a mi me falta.

Ahora, de estos datos, se usa la herramienta

ykpersonalize -ouid=3f7a64615f3c -a5ce3fb71c78292397678a556b1c0be02 -ofixed=cccccccccccb -c4bbbe24a0335

y el otp esta listo par ser usado. Esta información debe de estar guardada en la base de datos keystorage de KSM.

Con esto, la información entre el KSM, su tabla keystorage  y la OTP estan sincronizadas, solo falta actualizar el dato en el AuthServer, que es en donde vive la base de datos ykval.

En ykval tenemos la tabla `clients`
CREATE TABLE IF NOT EXISTS `clients` (
  `id` int(11) NOT NULL,
  `active` tinyint(1) DEFAULT '1',
  `created` int(11) NOT NULL,
  `secret` varchar(60) COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
  `email` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `notes` varchar(100) COLLATE utf8_unicode_ci DEFAULT '',
  `otp` varchar(100) COLLATE utf8_unicode_ci DEFAULT '',
  PRIMARY KEY (`id`),
  UNIQUE KEY `id` (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

En esta tabla, el id lo tengo mapeado a el id del usuario en mi aplicacion, active, create a 1, secret es una cadena de tamaño fijo que se usa para firmar la información del lado del cliente, esta cadena debe de ser aleatoria con un tamaño de 26 caracteres hexadecimales y el sistema autentifica con el correo electrónico, el cual esa tal cual en texto plano.

Agregando estos datos ya estamos listos para usar la infraestructura.

Si tienes dudas, manda un mensaje... con gusto te podemos ayudar.