211–220 of 222 posts
Equity is where the gold is, and each investor is an extra marriage partner who must be satisficed and can potentially upend everything.
Build a stable business, not an instant payday.
Earlier quoted context omitted.
> Cross key syncing service. Can’t work with FIDO/U2F, I’m afraid. The protocol works a little differently than most people expect, which is what allows the hardware token to “store” an unlimited number of auth credentials. What really happens at auth time is that the server (the one you are trying to authenticate to) sends a crypto package including the challenge and a key used to sign the challenge to the token. (T…
I've read about how some folks are using FIDO apps on devices like the Ledger Nano, designed to be crypto currency wallets. These allow the (FIDO) device identity to be exported and later restored onto a new device from the same product line. As I understand it, the experience would be a bit more like restoring a passkey on a new phone, but using a locally secured backup rather than a cloud vendor. Since reading abou…
The standard actually anticipates you might want to do that, so the token’s manufacturer can sign the token so that a relying party can whitelist (or, presumably, blacklist) certain tokens.
Earlier quoted context omitted.
You could buy a programmable open source security key instead, they recently opened their shop. https://tillitis.se/ Some of the people behind Mullvad VPN are associated with it.
That site is fucking garbage, and there doesn't even see to be a dock on what it supports. Like, programmable key is cool as an idea but I need smartcard support and a button on it to confirm transaction to replace YK usage...
Earlier quoted context omitted.
Well an interesting new approach to security tokens just launched: the tillitis tkey[1]. It has open source hardware and software. Unlike other security tokens that are based around storing your key where it can't be read, the tillitis tkey doesn't have any persistent storage and instead calculates your private key by hashing the program you've loaded onto the key, a user-supplied secret, and a per-device random secr…
I like the idea, but I'm worried about the FPGA being programmed to exfiltrate the secrets and re-flashed to the original program. With the Yubikey, it's mostly guaranteed that the device key remains on the device. Are there safeguards against this?
First: all registers and logic (LUTs) will always be cleared during the reset phase of the FPGA configuration. So any secrets stored there will be secure. We store the Unique Device Secret (UDS - the primary asset) in registers. Registers that can also only be read once between power cycling. The block RAMs (EBRs) however can be cleared or retain data based on the configuration Right now we have to touch the FW-RAM (implemented using EBRs) with the UDS for a few tens of cycles. After it being used, it is wiped from memory. So a successful exfiltration must trigger the warm boot-reconfiguration during that window of time. In order to make this harder (i.e. more time consuming) we do a few things:
1. We randomize when the UDS is moved to the FW-RAM and thus when the window to hit is. And we should not leak any indication when that is.
2. We use ASLR to randomize where and in which order the UDS is stored in the FW-RAM.
3. We use randomized data scrambling of the contents in the FW-RAM. And yes we do fill the memory with randomized, ASLRed data first.
The randomization control values are all stored in registers, and will be lost as part of the reset phase of the attack. So an exfiltration must:
1. Hit the window of time.
2. Extract the contents of the FW-RAM.
3. Be able to distinguish the random data words that make up the UDS from the other contents of the FW-RAM.
4. Descramble the UDS words and place them in the right order.
It is not an impossible attack, but it should take a long time. And it should not scale easily from one device to all other. One could automate it of course, but the work should be the same (multiple exfiltrations) for each device.
But we still think that the attack IS possible, and it is therefore out of scope of attacks that we mitigate for this version of the TKey. The next version will hopefully be able to keep the UDS in registers only. When we have that working, the threat model will be updated to reflect that.
Earlier quoted context omitted.
If you are looking for a tiny, Swedish company working in a similar area as Yubico, there is Tillits AB. Tillitis is a spin off from the Swedish VPN provider Mullvad. In contrast to Yubikeys, The Tillitis TKey as well as tools, device verification etc is 100% open source. https://tillitis.se/ https://github.com/tillitis https://mullvad.net/en (Full disclosure: I work for Tillitis.)
Interesting product, thanks for sharing. Can it hold gpg keys and interface with gpg-agent? I couldn't find that information.
The TKey does not have any persistent memory available for applications to store things. The idea is that we measure (calculate a keyed digest using BLAKE2s) the application during loading. The keyed digest (called CDI) is used as a base secret, random value by the application to derive the secrets the application needs. The Ed25519 signer for example derive its keypair based on the CDI.
A PGP application could use this to determinstically derive a keypair.
The FW application loader will also accept a User Supplied Secret (USS), which is also used during the calculation of the CDI. This means that the keypair derived will be based on the specific TKey device, the integrity to the device application and the USS. One way to use the USS is to control which keypair to derive. For example for SSH, different USS can derive keys used for different servers.
Also, a device application may use the CDI to derive wrapping keys, and then use authenticated encryption to protect a cookie that can be stored on the TKey client machine between usage.
We are working on providing libraries and examples for app developers to do this.
And to the yes part of the answer: Yes, a TKey could talk to a PGP agent and be called upon when needed. This is similar to how a SSH agent can talk to TKey today.
Earlier quoted context omitted.
>But it lacks programmability For a lot of us, that's a feature, not a bug.
Sure, I mean there will always be two main groups of clients on the market. Those who trust in openness and those who don't care, or even distrust it. So there will always be a place for Yubikey. But afaik there is nothing else out there right now like the tillitis key, programmable, 100% open, and already shipping.
Earlier quoted context omitted.
This is the zeitgeist, i get it- corpos bad. But it is such a simplified cliché to buy into so wholly. Public companies are capable of long term planning. Quarterly reviews do enforce efficiency. What you've seen play out again and again is good corporate governance from public companies, you just don't notice it and more's the pity.
What I've seen play out time and time again is that a company with a good product goes public or gets purchased, and then their good product gets worse. Often much, much worse. As a customer, I don't care why this is, but it is. That's why this is bad news every time it happens -- it's not that corporations are bad, it's that the products very often (but certainly not always) become undesirable.
"Caroline af Ugglas, on behalf of ACQ board of directors commented: …" This is weirdly enough a Swedish singer who had Eurovision Song Contest ambitions. https://www.youtube.com/watch?v=HE1Vy5lKuzw She's part of the Swedish upper class – the Swedish wikipedia page lists her as "baroness" (friherrinna), further accentuated by her name ("af" is the swedish variant of the german "von")
This is the artist: https://en.wikipedia.org/wiki/Caroline_af_Ugglas
Earlier quoted context omitted.
What I've seen play out time and time again is that a company with a good product goes public or gets purchased, and then their good product gets worse. Often much, much worse. As a customer, I don't care why this is, but it is. That's why this is bad news every time it happens -- it's not that corporations are bad, it's that the products very often (but certainly not always) become undesirable.
To be fair, I think a lot of the time a company's initial product is developed/sold in a way that is unsustainable for profitability, in order to attract users/customers/etc. Think "growth hacking", etc. By the time such a company is bought, it's already at the point where they need to start focusing on long-term profitability anyway, which means cutting costs and actually finding a plan to make money. This always ne…
But, as long as we're talking about possible causes, that startups do this sort of thing (catchy name like "growth hacking" or not) is a kind of deception that I object to anyway.
Releasing a product is a kind of promise, in a way. If a product is being released in an unsustainable way (growth hacking), the company should be calling that out from day 1.
I'm curious how Apple Passkeys will affect the Yubico business. Competition for U2F products may increase drastically as consumers begin adopting it. This may be prescient timing to go public for Yubico.
> I'm curious how Apple Passkeys Wait... Passkeys are from the FIDO alliance and both Google, Apple and Microsoft have pledged to implement passkeys for auth no? I don't think it's "Apple passkeys" any more than they're "Google passkeys" or "Microsoft passkeys". Which is why it's so scary... It's going to steamroll all other kind of auth with these three juggernauts behind it.