You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not sure if you would classify this as a feature request or a bug, but I've put it down as a bug as its (potentially) quite an important security flag missing from SecAccessControlCreateFlags.
I'm no iOS developer, but I was interested to see blinksh implements secure enclave storage of keys, and so I wanted to check how this was actually implemented.
I also note this from the Apple dev docs (my highlighting of the second phrase of the paragraph):
You could also combine the privateKeyUsage flag with other flags, using a bitwise OR to obtain additional protection for your key. For example, if you include the touchIDAny flag, you instruct the system to make the key available only when the system can authenticate the user with Touch ID (or a fallback passcode). See SecAccessControlCreateFlags for the complete list of available flags.
However, searching the blinksh code for touchIDAny (or indeed biometryAny since the touchIDAny form seems to be deprecated) yields no results.
I would have thought it was somewhat important that blinksh required touchID/biometry before using a key ? (Or at the very least give the user the option to mandate it).
The text was updated successfully, but these errors were encountered:
First of all, don't think it is a security bug, more like a feature. The key is still protected by the SE and it cannot be read, Blink is still the only app which can send "signature" requests to that key. Enabling biometryAny is about using what is considered "proof of user presence", but it is not a requirement of Hardware keys themselves (Yubikeys for example are ok with the user just "tapping a button", so definitely on the very low end).
We should definitely add this as a feature though. It is one extra step for security, as if your device is left unattended AND unlocked, and you also don't have Blink protected, someone could use it to log in to one of your servers and possibly install a key.
Also, we should create a "Security" tag in here as well, to give a path to request like yours. Thanks a lot for taking a look at our code! That's the beauty of having an open source shell :)
I'm not sure if you would classify this as a feature request or a bug, but I've put it down as a bug as its (potentially) quite an important security flag missing from
SecAccessControlCreateFlags
.I'm no iOS developer, but I was interested to see blinksh implements secure enclave storage of keys, and so I wanted to check how this was actually implemented.
My understanding of the code is that the magic happens on Line 65 of SEKey.swift.
I also note this from the Apple dev docs (my highlighting of the second phrase of the paragraph):
However, searching the
blinksh
code fortouchIDAny
(or indeedbiometryAny
since thetouchIDAny
form seems to be deprecated) yields no results.I would have thought it was somewhat important that
blinksh
required touchID/biometry before using a key ? (Or at the very least give the user the option to mandate it).The text was updated successfully, but these errors were encountered: