Yubico Forum

...visit our web-store at store.yubico.com
It is currently Wed Aug 16, 2017 3:57 pm

All times are UTC + 1 hour




Post new topic Reply to topic  [ 6 posts ] 
Author Message
PostPosted: Wed Apr 12, 2017 1:21 pm 
Offline

Joined: Wed Apr 12, 2017 1:14 pm
Posts: 1
Really enjoying my new yubikey but I'm trying to understand the PIN/PUK model. A big draw of having a yubikey for me is that (in principle at least), I'm less vulnerable to my machine being compromised, because the cryptographic keys I care about don't reside on it.

After accidentally entering my PIN 3 times incorrectly in gnupg and getting it blocked, I looked a bit more at the blocking procedure and was wondering if I'm still exposed to a different type of attack: a "for the lulz" attack that can't steal any keys from me, but can still cause me massive headaches by spuriously blocking my PINs and PUKs until I'm forced to reset my key. Here's the (hypothetical; I'm not necessarily actually this paranoid) scenario:

1. Attacker breaks into my computer
2. Attacker tries to steal muh keyz
3. Attacker gets frustrated, says "if I can't have them, nobody will"
4. Attacker enters my PIN incorrectly several times, followed by (potentially if it's enabled) my PUK
5. Attacker moves on, leaving me to clean up the mess of having to reset my yubikey and reprovision new keys all over the place

Is this a potential attack or am I missing something that makes it hard? It seems like this would be alleviated if each failed PIN/PUK attempt required me to physically touch the yubikey button to reactivate it, thus preventing all automated attacks that don't have physical access. Is it possible for me to configure my key to require a button press on failed PIN/PUK attempts?


Top
 Profile  
Reply with quote  

Share On:

Share on Facebook FacebookShare on Twitter TwitterShare on Tumblr TumblrShare on Google+ Google+

PostPosted: Wed Apr 12, 2017 8:55 pm 
Offline
Yubico Team
Yubico Team

Joined: Thu Oct 16, 2014 3:44 pm
Posts: 294
First, to clarify...

GnuPG/OpenPGP doesn't have a PUK, PIV does.

OpenPGP
PIN: 3 retries then locked
Resetting Code: none by default
Admin PIN: 3 retries then locked

PIV
PIN: 3 retries then locked
PUK: 3 retries then locked (device must then be reset)
Management Key: doesn't lock
(may be useful - https://developers.yubico.com/PIV/Intro ... ccess.html)

To your question, no, if someone has physical access to your YubiKey, or if they have control over your computer and the YubiKey is plugged in, the OpenPGP and PIV applets can be locked out / reset, and OATH applet can be reset / credentials deleted.

A feature request for a change to the OpenPGP applet could be submitted on GitHub, if you wish, but I'm not sure the viability of this scenario - https://github.com/Yubico/ykneo-openpgp/issues


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 09, 2017 2:32 pm 
Offline

Joined: Tue Jul 18, 2017 12:13 am
Posts: 6
I think the problem is worse than described. Not only can the attacker force a key reset, they can reset the device and install a new PIN and keys. If you read the public key/certificate from the device for encryption, you might not even realize it is changed and use it. You would only find out when you went to decrypt the data or access the private key in some way, and your PIN would not work. The user could then ransom you for the PIN to decrypt the data. (I now feel you have to test decryption every time you read a certificate, or check that it is signed by a valid CA.)

This is worse than storing keys in the file system because at least you have OS-control over who can read and modify file system files. I am researching how to control USB access to the device on Linux.


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 09, 2017 4:22 pm 
Offline

Joined: Tue Jul 18, 2017 12:13 am
Posts: 6
It seems the way to control access on Ubuntu 14.04 is to change the permissions of the pcscd socket file:

Code:
sudo chown user:user /var/run/pcscd/pcscd.comm
sudo chmod 0660 /var/run/pcscd/pcscd.comm


This controls who can access the PIV card, and would have to be done at boot, before non-root users can access the system. Changing the permission of the USB character device has no effect, probably because pcscd is running as root.


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 09, 2017 5:16 pm 
Offline
Yubico Moderator
Yubico Moderator

Joined: Tue Jan 05, 2016 5:03 pm
Posts: 21
bmomjian wrote:
I think the problem is worse than described. Not only can the attacker force a key reset, they can reset the device and install a new PIN and keys. If you read the public key/certificate from the device for encryption, you might not even realize it is changed and use it. You would only find out when you went to decrypt the data or access the private key in some way, and your PIN would not work. The user could then ransom you for the PIN to decrypt the data. (I now feel you have to test decryption every time you read a certificate, or check that it is signed by a valid CA.)

This is worse than storing keys in the file system because at least you have OS-control over who can read and modify file system files. I am researching how to control USB access to the device on Linux.


Hello Bmomjian,

Not having a PIN / PUK lockout after bad entry would lead to an attacker to be able to brute force your PIN / PUK and gain access to your certificate and use it maliciously as well as being able to change the PIN / PUK and lead to locking you out. as far as security, Best practice is *NOT* to share a single YubiKey among multiple users and *NOT* leave the YubiKey in the machine indefinitely you should authenticate and remove until needed again. This is where the best security comes from if an attacker gains remote access to your system they will not be able to gain access to a physical device if it is not attached to the machine.

Best Regards,
Matthew
Yubico Support


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 16, 2017 2:19 pm 
Offline

Joined: Tue Jul 18, 2017 12:13 am
Posts: 6
Well, everything I do is on multi-user machines, so I have to consider these issues.

I realize you need to have a lockout for failed PIN/PUK attempts. I think the big change from the FIPS standard is that normally a lockout makes the device/card unusable forever, while the Yubikey can be reset and made usable, perhaps invisibly to the owner (until they try to use their old pin). Another point is that certificates (with the public key which is used for encryption) does not require a PIN, so you might not know until you try to decrypt or sign something using the private key. I realize making the Yubikey unusable permanently is also not a good option --- I am just pointing out that the ability to reset it also has downsides.

On Linux the Yubikey tools access the device via pcscd, so I modified the pcscd startup script with this addition which sets the permission on the devices to a specific user so no one else can access the device:
Code:
SOCKFILE="$IPCDIR/pcscd.comm"
PCSCD_USER="laptop11"
while :
do      [ -S "$SOCKFILE" ] && break
        sleep 0.1
done
chown "$PCSCD_USER":"$PCSCD_USER" "$SOCKFILE"
chmod 0660 "$SOCKFILE"


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group