[tialaramex]

That doesn't work.

The attack recovers an ECDSA private key for one account. So e.g. maybe your Google account. But this key does not exist when you receive the Titan in its packaging, it's created (randomly) when you enroll the key for your Google account.

These devices create entirely random ECDSA private keys for every single enrollment, and this attack recovers one key, using a real challenge from the relying party for that key. If they want your GitHub, or Facebook or your US government account, those have separate keys which need a separate attack.

[sneak]

It's been a while since I've read the U2F spec and my info may be a major version out of date but I understand that the enrollment-specific key was encrypted to the long term device key then returned to the service for storage.

The attack to mount would be against the long-term device-specific key, no?

[tialaramex]

You are correct about how this works. I think the "Side Journey To Titan" paper makes it obvious the authors also understand how it works.

So if you can magically summon working attacks, you would choose the symmetric AES key yes.

One conclusion you could draw from this paper is the authors are idiots and didn't realise they should attack that key or else didn't have the relevant expertise to do so.

Another, I suspect far more likely conclusion is that protecting AES keys in dedicated security hardware is a problem lots of people already put effort into and these researchers wisely concluded they wouldn't get any traction there because this is a standard component.