Yubico Forum

Re: programming the keys

2009-03-27T20:35:34+01:00

> Perhaps the script that Ferrix provided for reprogramming to a static password will be helpful as a basis for creating a Linux script to do what needs to be done. It's at
>
> http://s3.collectivesoftware.com/statickey.wsf

There are some helpful details in that script, but it still doesn't show me how I can modify the Linux programming software to be able to set the programming password. Until we can do this, it is trivial for an attacker to reprogram the key and DoS the user out of our servers, or activate the auto-navigation feature to obtain an OTP for cracking a user account.

> Also I assume that you've seen the stuff at
>
> http://www.yubico.com/developers/personalization/

Yes, but it doesn't (yet) have source code so I can't get the information I need from that. It does have the ability to set the password, but only by going through a Windows GUI. That's OK for testing, but isn't going to work for us with thousands of production users. At best, this would require mousing keys between the personalization GUI and a program that can generate random keys and then install those keys into the YubiPAM database.

What we really need is a way to program the tokens, disable the auto-navigation feature, and protect the token from reprogramming in the field, all from a Linux command line.

Statistics: Posted by Greg Woods — Fri Mar 27, 2009 8:35 pm

Re: programming the keys

2009-03-27T19:52:31+01:00

Greg,

Perhaps the script that Ferrix provided for reprogramming to a static password will be helpful as a basis for creating a Linux script to do what needs to be done. It's at

http://s3.collectivesoftware.com/statickey.wsf

Also I assume that you've seen the stuff at

http://www.yubico.com/developers/personalization/

Dick

Statistics: Posted by Dick — Fri Mar 27, 2009 7:52 pm

Re: programming the keys

2009-03-27T17:45:17+01:00

JakobE wrote:

> If there is a concern that an attacker/saboteur would reconfigure the Yubikey, set the configuration access code.

The problem here is that this is settable, as far as I have been able to find, only using a GUI under WIndows. This is OK for testing with a small handful of users, but it isn't going to work for us for thousands of users in production. The Linux software I have been able to find on Google could be scripted, but it does not allow the programming access code to be set, or even for the token to be programmed if the access code is already set. Requiring every token to go through a Windows GUI is a non-starter for us.

I would like to modify the Linux code so that it can set the password, but I haven't found the source code for the Windows version yet so I don't have enough information to do this.

> 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.

How can I tell what version of the firmware I have and whether or not that version of the firmware has the protection?

> 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.

Same problem with inability to set the access code without using a Windows GUI.

Statistics: Posted by Greg Woods — Fri Mar 27, 2009 5:45 pm

Re: programming the keys

2009-03-27T15:21:48+01:00

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

Statistics: Posted by Jakob — Fri Mar 27, 2009 3:21 pm

Re: programming the keys

2009-03-27T10:06:56+01:00

Dick wrote:

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.

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

Statistics: Posted by Simon — Fri Mar 27, 2009 10:06 am

Re: programming the keys

2009-03-26T07:01:47+01:00

Statistics: Posted by Dick — Thu Mar 26, 2009 7:01 am

Re: programming the keys

2009-03-26T05:09:11+01:00

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.

Statistics: Posted by Greg Woods — Thu Mar 26, 2009 5:09 am

Re: programming the keys

2009-03-26T01:49:36+01:00

Greg Woods wrote:

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

Statistics: Posted by Dick — Thu Mar 26, 2009 1:49 am

Re: programming the keys

2009-03-25T23:26:11+01:00

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.

Statistics: Posted by Greg Woods — Wed Mar 25, 2009 11:26 pm

Re: programming the keys

2009-03-25T22:39:09+01:00

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

Statistics: Posted by Dick — Wed Mar 25, 2009 10:39 pm

Re: programming the keys

2009-03-25T13:06:29+01:00

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

Statistics: Posted by Greg Woods — Wed Mar 25, 2009 1:06 pm

Re: programming the keys

2009-03-25T05:26:01+01:00

Regarding the trigger function, see the following thread:

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

Dick

Statistics: Posted by Dick — Wed Mar 25, 2009 5:26 am

programming the keys

2009-03-24T22:02:05+01:00

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.

Statistics: Posted by Greg Woods — Tue Mar 24, 2009 10:02 pm