Yubico Forum

...visit our web-store at store.yubico.com
It is currently Tue Jan 30, 2018 2:10 pm

All times are UTC + 1 hour




Post new topic Reply to topic  [ 8 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: 349
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: 7
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: 7
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: 27
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: 7
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  
PostPosted: Sun Sep 10, 2017 9:58 am 
Offline

Joined: Thu Sep 07, 2017 5:16 pm
Posts: 9
i have asked, the attack is possible and if someone guess wrong pins OpenPGP applet must be resetted and you will lose private key.
i think that software solution is NOT a solution in fact you own a yubikey exactly because you don't trust (always) your computer and especially other computers.

the only solution is having an offline backup to be used only in case yubikey stops working (before pushing keys on the yubikey).
having a backup is always a good idea.


Top
 Profile  
Reply with quote  
PostPosted: Sun Sep 10, 2017 3:16 pm 
Offline

Joined: Tue Jul 18, 2017 12:13 am
Posts: 7
With OpenPGP, as I understand it, only the private key is stored on the Yubikey --- the public key is on the computer, so the worst someone can do is to replace the private key, and you would have to restore it.

With PIV, the public and private keys are stored on the Yubikey, so someone can reset the Yubikey and replace both the public and private keys. You could then start encrypting things with the replaced public key and not know about it until you tried to tried to decrypt it with the private key that you now can't access because the PIN is changed. Three failed PIN and PUK attempts and now you will never be able to decrypt the data that was encrypted with the replaced PIV public key.


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

All times are UTC + 1 hour


Who is online

Users browsing this forum: Google [Bot] and 2 guests


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