search

solokeys / solo1

Solo 1 firmware in C
https://solokeys.com/
Other
2.3k stars 274 forks source link

Longpress option for touch? #70

Open KlavsKlavsen opened 5 years ago

KlavsKlavsen commented 5 years ago

One issue - which annoys a lot of us, when using touch mode on yubikey (which is a LOT safer) - is that we use https://www.passwordstore.org/ - which keeps each password in its own file - and gpg encrypts that file. That works great - and when touch is required for each operation, no one can steal my passwords - as it'll just 'blink' and wait for my touch..

However.. for certain operations.. we really would like a way to "longpress".. or "auto touch" for multiple gpg operations..

f.ex. When we want to run ansible (remote operations) on 100+ machines (that only takes ~5-10 seconds to login to them all ) (using ssh-agent feature of gpg-agent)

or when I need to reencrypt my passwordstore (to give access to another person - or remove ones access) - since both times, I need to touch for EVERY server|password.

I would like to be able to setup so "touch for x times.. or for X amount of time.." - enabled "longpress" - where the key will "act as if I am still touching it" for ~10 seconds or so - giving me time to do the operations I need to, without having to touch for every single one (ie. disabling fix setting for that specific operation type (sign, encrypt.. )) for that small timeperiod..

merlokk commented 5 years ago

It will be security hole.... You cant control access to keys. You can't prevent a hacker to sign bitcoin transaction as a sample... or login to bank account... or something like

KlavsKlavsen commented 5 years ago

@merlokk What are you talking about? how is it a security hole that I - with touch enabled - can have a longpress option - so IF I choose to longpress.. it then "disables" the touch requirement for X seconds? Yubikey f.ex. has optional touch.. so the alternative that many uses, is that touch is just disabled - which is much worse for security, than just having the option to "disable touch requirement for X seconds/X times".

merlokk commented 5 years ago

as for disable touch: it definitely much worse. but... enable for X seconds is not a good choice. Hacker can easily check this situation and do his deeds) at that time. Maybe makes sense to do this with some setting that disabled by default.

KlavsKlavsen commented 5 years ago

as for disable touch: it definitely much worse. but... enable for X seconds is not a good choice. Hacker can easily check this situation and do his deeds) at that time. Maybe makes sense to do this with some setting that disabled by default.

My exact suggestion. hackers have to own your working-machine - to make use of it "when you use it".. and thats why I wanted X times (and max X time - ie. timeout).. so it is only a small window - the user can configure.. I can see that even my best colleagues do not enable touch - as their ansible/passwordstore updates then becomes impossible (or touch 100+ times)..

conorpp commented 5 years ago

This sounds reasonable to me. Long touch/press -> token changes LED pattern so you know it's unlocked. Then timeout and back to normal. I think we'd have to be careful not to make it easy for people to trigger accidentally and cause confusion. Maybe long touch when the first decryption request is received?

Marking as future enhancement for when we start on our GPG/SSH interface

KlavsKlavsen commented 5 years ago

@conorpp Sounds exactly like I pictured it - and yes, it would be fine if it only triggered if there hadn't been a previous touch event "within X seconds".. so its the first time you startansible or passwordstore reencrypt - that you have to longpress. Soo much looking forward to a real open source key, with the gpg/ssh functionality :)

szszszsz commented 5 years ago

I understand the need. The implementation of the solution is feasible as well. Is it not however a design issue by the side of the client application? The user feedback is designed to confirm one, and only one operation. Here we want to confirm an operation, which is e.g. a decryption of a series of keys in the password store. To achieve such it should be sufficient to decrypt a shared secret, which would be used for decryption of the mentioned passwords. @KlavsKlavsen would that not work for you? I like the idea of confirming a known number of the transactions at once (one, to be exact), hence the proposition.

KlavsKlavsen commented 5 years ago

@szszszsz In theory yes.. but when used with ssh (f.ex. for ansible which logs in many times via ssh - and as we do not want to export our private key) and gnupg (for passwordstore reencrypt of many files) - they are NOT built to do it that way.. and I'm not sure its very feasible to do so.

pjz commented 5 years ago

How is this different than setting default-cache-ttl or max-cache-ttl in your gpg-agent.conf ?

KlavsKlavsen commented 5 years ago

@pjz You can't cache a touch requirement (thats the point of touch ;)

pjz commented 5 years ago

Oh, hm. I thought it would cache that you had authenticated and keep your key cached in RAM for that long.

KlavsKlavsen commented 5 years ago

@pjz You can test out a yubikey.. the private part stays on the stick. If you set it to "require touch" on a yubikey - its for EVERY time you want the operation you requested (sign, authenticate or decrypt) - and the private key is not cacheable - as it stays on the stick (thats the whole point otherwise the private key could be stolen)

pjz commented 5 years ago

Okay, reading this when it's not the middle of the night has me understanding and agreeing with @KlavsKlavsen . :+1: