My recent changes to MODE_YUBICO

Hi Cornelius,

I’ve tried to write up my thinking and goals here. This might clarify
my reasoning:

Tokentype yubikey in privacyidea================================

Goals for the implementation:

  1. Configuring and enrolling the yubikey token should be as easy as
    possible. So we should use sensible defaults where possible.

  2. A yubikey configured for privacideas tokentype yubikey should be
    also usable with yubicos cloudservice (so we can easily check our
    implementation for compatibility).

  3. Tokentype yubikey should be usable with software compatible with
    yubico’s cloudservice, e.g. pam_yubico (simple to debug) or OTP
    with Kolab.

  4. A token initialized with the yubikey personalization tool according
    to yubico’s documentation (see below for URLs) should simply work
    and be almost indistinguishable from a token initialized by

  5. Already initialized tokens which are not compatible with Yubico’s
    cloud service should continue to work with privacyidea. It might be
    useful to warn when tokens are not compatible.

Restrictions when initializing the yubikey

The OTP generated by a yubikey in AES mode must be 44 characters. The
first 12 characters are the public ID of the token, the rest will be
the OTP. When initializing with the yubikey personalization tool you
can create an optional private identity that is included as an input
parameter in the OTP generation algorithm. It is not used for
identification of the token.

For a short documentation how to initialize a token see
or the video at .

According to the
first two characters of the modhex prefix are “cc” for factory
programmed tokens and “vv” should be used for customer programmed
tokens for the Yubico cloud service. The personalization tool will
create the prefix automatically. To reach goal 2 we should generate a
“vv” prefix, but might want to enable users to set a custom prefix
when mass enrolling tokens.

=> needed change: move privacyidea to a default of “vv” and a random
prefix of 5 bytes, so we have a prefix of 6 bytes (modhex 12) when
mass enrolling a MODE_YUBICO token.

Pull request:

It would be possible to convert the serial number of the token to
modhex and use that as a prefix. pro: prefix will be unique
(depends on unique serial numbers) cons: makes the token
identifyable without need.

=> needed change: allow custom prefix different from “vv” with a
command line option

=> needed change: token.enroll.yubikey.html should have a description
how to get compatible tokens.

I’m unsure what “emit a public UID” changes. May be some clarifying
words are needed.

=> possible change: OTP key is called “Secret Key” in the
personalization tool.

A token created with mass enroll will have the serial
UBAM_. A token enrolled with the webui will get a
random serial number. Can/Should the be fixed? See goal 4.

token.enroll.yubikey.html: Test Yubikey is simply a text field to
display the OTP, or what gets tested?

Verify a token with the API

Here’s the upstream documentation:

The only problem with troubleshooting is that the trouble shoots back.