YubikeyHelp: Difference between revisions
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
__NOTOC__ |
__NOTOC__ |
||
This page is about creating your own validation server, to complement the existing documentation. |
This page is about creating your own Yubikeys validation server, to complement the existing documentation. |
||
/!\ Beware you need to change the key data in you Yubykey to be able to manage your own accounts, and that doing so will prevent you from using Yubiko special services (most being available for demonstration purpose, and most being replacable, like having your own OpenID server; but you can still have a second key if you want to access Yobiko's services). |
/!\ Beware you need to change the key data in you Yubykey to be able to manage your own accounts, and that doing so will prevent you from using Yubiko special services (most being available for demonstration purpose, and most being replacable, like having your own OpenID server; but you can still have a second key if you want to access Yobiko's services). |
||
Before we go, you must understand this key is not designed to allow subscribing to different providers (like with distributing SSH public keys), but to contain full or partial credentials for '''one account on a particular provider'''. If you need to access say your own machines and your staff corporate machines via SSH and PAM+yubikey for example, then you must have two keys. As this is symetrical cryptography, both ends needs to access the |
Before we go, you must understand this key is not designed to allow subscribing to different providers (like with distributing SSH public keys), but to contain full or partial credentials for '''one account on a particular provider'''. If you need to access say your own machines and your staff corporate machines via SSH and PAM+yubikey for example, then you must have two keys. As this is symetrical cryptography, both ends needs to access the secret and i guess you would not share your key between your personnal accounts and staff accounts (in the previous example). In this model, an account provider programs keys and distribute them among users, which is perfectly appropriate for personnal or corporate purpose but not for a service provider. Nevertheless, this provider can act as an authentication service provider too, using [[OpenId]] for example. |
||
== Understanding the Key == |
== Understanding the Key == |
Revision as of 18:15, 7 June 2009
This page is about creating your own Yubikeys validation server, to complement the existing documentation.
/!\ Beware you need to change the key data in you Yubykey to be able to manage your own accounts, and that doing so will prevent you from using Yubiko special services (most being available for demonstration purpose, and most being replacable, like having your own OpenID server; but you can still have a second key if you want to access Yobiko's services).
Before we go, you must understand this key is not designed to allow subscribing to different providers (like with distributing SSH public keys), but to contain full or partial credentials for one account on a particular provider. If you need to access say your own machines and your staff corporate machines via SSH and PAM+yubikey for example, then you must have two keys. As this is symetrical cryptography, both ends needs to access the secret and i guess you would not share your key between your personnal accounts and staff accounts (in the previous example). In this model, an account provider programs keys and distribute them among users, which is perfectly appropriate for personnal or corporate purpose but not for a service provider. Nevertheless, this provider can act as an authentication service provider too, using OpenId for example.
Understanding the Key
The yubikey hold several interresting data inside. A few of them can be modified by the user :
- public name (0 to 16 characters): the publicly advertised name of the key
- private name (6 characters): the secret name of the key
- management password: a secret used to allow changing the key data
- AES key (32 characters hexa): the secret key used to create the OTP
The public name can be whatever you want; you can, for example, set it to an empty string if you don't want to disclose to which it belongs (in case the key is lost), or use the name of your company, or even the name of the user, ... This field is often called the fixed part.
The private name can be whatever you want. It is not an important part of the security system, but can be used to identify the key uniquely. It can hold the real username for exemple (or a number, as the field is quite limited in length). It can also be used to shared the same AES key among user and still be able to distinguish the keys (to be able to revoke key rights if the key was lost, for example). This field is often called the uid part.
The management password is necessary to be able to change the data of the key. Beware not to loose it or you'll never be able to modify it (even if it seems to be possible to use the AES key instead, but i guess you would have lost it either). This field is often called the acc_code part.
The AES key is a secret number used to encrypt data and do the real security stuff. This field is often called the key part.
Creating your own Key
Installing the Personnalization Tool
Get the latest tarball from this page: http://code.google.com/p/yubikey-personalization/ (currently http://yubikey-personalization.googlecode.com/files/ykpers-0.92.tar.gz) and uncompress it.
Install the needed build dependencies:
apt-get install libusb-dev
In the source directory:
./configure make make install
(This will install things in /usr/local, but you can pass parameters to the configure script to install it elsewhere)
Updating Key Data
# ykpersonalize -ouid=ilichrhvicil -ofixed=hfighehn Passphrase to create AES key: Firmware version 1.3.5 Touch level 8880 Program sequence 8 fixed:hfighehn uid:cccrcccccrcc key:iefrgfvdhufdgniljcnjirclkbferjbi acc_code:cccccccccccc ticket_flags:APPEND_CR config_flags:
blabla