51–60 of 215 posts
Previous firmware didn't restore U2F key from backup, but current one does. It also didn't have any kind of lockdown, so I did it via UDEV rules, luckily current firmware has a lock button, which even sends "Super-l".
I would also love onlykey-cli be ported to Python3.
Somebody mentioned here that onlykey isn't fit for keychain use, yet mine is totally fine and USB port shows virtually no signs of wear.
Earlier quoted context omitted.
The "security" of this device is a joke, just look at how randomness is derived: unsigned int analog1 = analogRead(ANALOGPIN1); RNG.stir((uint8_t *)analog1, sizeof(analog1), sizeof(analog1)*2); unsigned int analog2 = analogRead(ANALOGPIN2); RNG.stir((uint8_t *)analog2, sizeof(analog2), sizeof(analog2)*2); (See [0] for a comprehensive summary of why this is a terrible thing to do) And yeah, analogRead() is a function…
It's not 'trivial' to extract the keys - all modern uCs have flash readout protection bits. It's probably easier to do than to read the secure element from your iPhone or extract keys from your SIM card or your credit cards, but it's not something you can do without specialized skills and equipment (although there are companies that provide commercial flash readout services).
There's a reason we have real secure elements with anti-tamper mechanisms. The problem is that as far as I know there aren't any that you can develop for without signing an NDA.
Thanks for all of the interest in OnlyKey! Full disclosure, I work for CryptoTrust and am on the team that makes OnlyKey. I wanted to try to address the questions/concerns in this thread in one place and provide some useful links for more information. OnlyKey started from a successful kickstarter launch in 2016 and has grown to become a popular product for businesses and individuals. - OPEN SOURCE - If you are lookin…
I'm searching for a key that also works as a smartcard for winows on prem active directory authentication, as well as FIDO2 support.
Or a key that has software which allows this.
edit: changes should be chance
Trezor T is vastly superior solution for U2F / WebAuthn and also fully open source. The main advantage is super mature backup (Shamir's secret sharing) and PIN-locking with exponential escape. Being a Bitcoin hardware wallet, security is very well tested.
Given the history of the cryptocurrency field, A is very far from implying B. And there's at the very least the Ledger analysis[1], which reveals several vulnerabilities. (The core issue for me is the order->backdoor->return issue - it doesn't seem there's a way to verify integrity of device or supply chain)
[1] https://www.ledger.com/our-shared-security-responsibly-discl...
Security keys are the heart of security and we desperately need open-source solutions on this. Kudos for doing it. Now, I must point out a few things: 1. Please don't call your solution "Open-source", when you do not have not even the schematics uploaded to github. 2. (this item is an open problem without a solution yet) how do I make sure the source code and the (still missing) hardware information actually correspo…
The "security" of this device is a joke, just look at how randomness is derived: unsigned int analog1 = analogRead(ANALOGPIN1); RNG.stir((uint8_t *)analog1, sizeof(analog1), sizeof(analog1)*2); unsigned int analog2 = analogRead(ANALOGPIN2); RNG.stir((uint8_t *)analog2, sizeof(analog2), sizeof(analog2)*2); (See [0] for a comprehensive summary of why this is a terrible thing to do) And yeah, analogRead() is a function…
https://github.com/trustcrypto/OnlyKey-Firmware/blob/master/...
The funny thing is they have a "Source code reviewed by Codacy" badge on the readme claiming the code is grade A... but if you actually click through, of course Codacy didn't pick up the .ino file at all, so in fact nothing of substance is being reviewed. That .ino file wouldn't pass any style review... it's a mess.
Anyway, looks like that firmware is incomplete (e.g. "onlykey.h" is missing). Just a quick scroll through the code gives me zero confidence in this thing, code quality wise. Someone who can't consistently indent code almost certainly isn't qualified to be writing security-critical software.
Edit: looks like the rest of the code is here, and yeah, it doesn't inspire much confidence (7000+ lines of code in okcore.cpp, ouch): https://github.com/trustcrypto/libraries/tree/master/onlykey
Earlier quoted context omitted.
The "security" of this device is a joke, just look at how randomness is derived: unsigned int analog1 = analogRead(ANALOGPIN1); RNG.stir((uint8_t *)analog1, sizeof(analog1), sizeof(analog1)*2); unsigned int analog2 = analogRead(ANALOGPIN2); RNG.stir((uint8_t *)analog2, sizeof(analog2), sizeof(analog2)*2); (See [0] for a comprehensive summary of why this is a terrible thing to do) And yeah, analogRead() is a function…
It's not 'trivial' to extract the keys - all modern uCs have flash readout protection bits. It's probably easier to do than to read the secure element from your iPhone or extract keys from your SIM card or your credit cards, but it's not something you can do without specialized skills and equipment (although there are companies that provide commercial flash readout services).
Security keys are the heart of security and we desperately need open-source solutions on this. Kudos for doing it. Now, I must point out a few things: 1. Please don't call your solution "Open-source", when you do not have not even the schematics uploaded to github. 2. (this item is an open problem without a solution yet) how do I make sure the source code and the (still missing) hardware information actually correspo…
Optionally for first line of defense, the assembly could be fastened with some less common like a torx or square screw head and it could come with a pack of small holographic security stickers to place over the screw.
Edit: You'd want it to be an unassembled kit so that you can provide your own hardware if you wanted instead of relying on what is provided for you if you wanted to be super cautious.