Yubico Forum

We are looking to integrate Yubikeys into an existing Linux-based authentication system (which means software that is Windows-based is not an option).
We have the YubiPAM module working under freeradius, modified to use a 4-digit PIN for two-factor authentication.

For programming the tokens:
Is there any way to set the password using the Linux software? If there is it isn't documented. Anybody have plans to implement this or already done it?

I still have open questions about the level of security provided by
something which is actually connected to the PC. If the token could be
remotely activated, that's a huge potential security hole. I suspect
that might be possible in a couple of ways. One, there is this setting
which looks like it simply enables the feature. I don't know what the
trigger is though so I can't test:
[-]allow-hidtrig set/clear the ALLOW_HIDTRIG configuration flag.

Does anybody know what this flag actually does? Is there in fact a way to send commands to the token that will cause it to activate and spit out an OTP?

Also, the auto-login feature is potentially dangerous. It seems likely
that a compromised workstation could be made to reset the USB bus and
trigger the function just the same as if the user had just plugged the
device in. The documentation also says that the auto-login can be
programmed without using the password, so users can update it. That
seems dangerous as well. We would like to get clarification
from Yubico about those two features.

Regarding the trigger function, see the following thread:

http://forum.yubico.com/viewtopic.php?f=6&t=291

Dick

Thank you for the pointer. I will be playing around with the personalization software later today, and if I can verify that the trigger feature is off by default and can be turned on and off as described, it will alleviate that concern.

This still leaves the concerns about the auto-login feature, and whether or not there is a way to protect the Yubikey from being reprogrammed by an attacker, without having to plug it into a Windows box.

--Greg

One can set a programming password to prevent reprogramming of certain aspects of the YK. Unfortunately, I believe that reprogramming the auto-login does not require that password. I have previously suggested that this should be changed since the auto-login could be maliciously reprogrammed by malware and is a very powerful feature in that it utilizes the "Run" command.

I don't know whether reprogramming the trigger function is controlled by the programming password or not since the personalization tool doesn't provide a means to change the trigger function and I haven't gone past that point in programming the YK. I'd be interested in what you learn in that regard.

Thanks.

Dick

Looks like you have only seen the Windows version of the personalization software. On the Linux side, I don't see any way to set the programming password, or to program a token if it already has a password set. It does, however, include the ability to set the ALLOW_HIDTRIG flag. Conversely, the Windows software allows setting and specifying a password, but doesn't let you set/clear the trigger flag. I expect we won't be able to deploy Yubikeys to a large number of users until the programming software is a little more developed, but I am still in the process of determining this.

Also, I have determined that the Linux programming software will not work on any Red Hat derived system, such as Fedora or CentOS. This is because, apparently, Red Hat has compiled the usbhid driver into the kernel rather than providing it as a module. So there is no way to unload the driver and reload it with the quirk parameters, which is necessary in order to avoid the "claimed by another driver" problem.

From reading the source code, it appears that it is not possible to do anything to the token without also writing an AES key, which requires that you either have access to the existing key, or generate a new key, which then would not allow the token to be used to log in as that user any more unless you also have access to the authentication server. If this is the case, it removes the concern about the trigger flag being set and then triggered as a way to break into the user's account.

The auto-login does remain a concern. It is a risk that we may or may not be willing to assume, but it would certainly be better from the security standpoint if this function could be disabled.

You are correct that I haven't looked at the Linux programming tool. I'm afraid that I don't know much about Linux. I guess the nature of community projects such as this leads to different paths with inconsistent capabilities.

I agree that the need to enter the AES key in order to program the YK would effectively preclude the trigger from being used to enter the user's account. I was originally thinking that the trigger in combination with the auto-login seemed particularly problematic, but on further thought I realized that the auto-login only occurs when the YK is first plugged in so I don't think the trigger would have any interaction with the auto-login. That, together with your observation, would seem to pretty much resolve my concern with the trigger. I'm still uneasy about the auto-login, but perhaps on further reflection will realize that my concern there is also unjustified.

Regards,

Dick

It is probably possible for an attacker to cause the USB bus to be reset, which might temporarily interrupt power to the token and cause it to power up again, thus going into auto-login if that has been set. Since auto-login can apparently be turned on by the user (or the attacker), without knowing the programming password, this is definitely a concern if everything I think I know about it is correct.

Good point. I guess the bottom line is that it would make sense that any changes in the operation of the YK should require entry of the programming password to minimize these potential problems and, perhaps, others yet unimagined as well.

Thanks for sharing the thinking on this.

Dick

Yes, that is definitely the case, and we are in the process of making this change.

It isn't unlikely that we'll drop the auto-login feature altogether, it doesn't work well (keyboard language dependent) and adds complexity and opens up for concerns like this.

/Simon

I think most have been said already, but just to summarize I would like to make the following points:

The HID trigger feature is configurable and this means you leave it off if you don't accept the potential vulnerability of a Trojan sending a fake trigger request. These flags cannot be changed without a complete reconfiguration. This means that an attacker that flips this flag to on will kill the current AES key and thereby simply making the key useless to the service it is intended for. If there is a concern that an attacker/saboteur would reconfigure the Yubikey, set the configuration access code. This effectively prevents reconfiguration.

The automatic navigation was previously seen as a gizmo that has been used for test and "playing around". It was a design parameter that this function should be configurable independently of the OTP configuration. Therefore, there is no password on it. Given that this has been seen as a potential risk, we've made a firmware change that locks the auto navigation configuration if the configuration access code is set. Therefore, if you don't like the automatic navigation feature, just leave it blank and set the configuration access code and the function will remain dead.

Hope this answers and addresses all concerns.

Regards,

JakobE
Hardware- and firmware guy @ Yubico