@CaffeineAddiction @forest Thanks it makes a lot of sense!

No problem!

You normally do have other ways though ... in the case of a cloud box you can go in through the cloud console ... and in the case of a physical box physical access is root access.

Yup. As long as you treat losing the private key as losing the ability to log in with it.

The key isn't used to encrypt data either (it's only used for authentication), so in theory, you could remove the public key from the server and publish the private key, and no harm would come from it (as long as the server no longer accepts it). So it's purely used to let you in over SSH.

I suppose it gets annoying if the setup of the public key on the server relies on another person, e.g. some kind of administrator and this person is only there to work once a week..

For sure, although that's an issue no matter what type of authentication you use.

@forest eh, kinda ... ssh key is technically a pub/priv key of some algo which may or may not be used to encrypt other data. In theory you shouldnt use it for anything other than ssh and you should gen a secondary key for encrypting and signing ... but not everyone does

@CaffeineAddiction Well it's not being used by SSH to encrypt any data.

In theory you could use it for something else, but you'd know if you were doing that.

Isn't using SSH a way to make a secure connection between a client and a host? Or, yes, this is it, but the key pair one uses is only used for the connection, and then something else is used to encrypt communication between the client and the host?

lol, yah ... I decided to gloss over that part to avoid confusion

like forest said ... the key isnt used for encrypting things ... kinda

it is used to async encrypt a shared sync key between 2 computers

and then uses the sync algo to do further communications from that point on

so, ssh technically does use the key for encrypting 1 thing ... but its splitting hairs

@CaffeineAddiction It's not used to do that.

ssh uses a diff pub/priv key pair for that initial communication?

It's used for authentication, not part of a hybrid cryptosystem. The key exchange is done with a totally different algorithm irrespective of the public key you're using for authentication. It's actually not public key encryption either. It's key agreement, since both sides generate a public and private key and mutually exchange them, then discard them both after use.

@CaffeineAddiction It always does. It uses some form of DH (usually either DHE or ECDHE, typically x25519).

kk

Good to know, thanks!

g'day all - what do you think of this answer? security.stackexchange.com/a/267692

(there were two answers with a similar, thorough pattern from the same user)

(and then one was deleted)

would any of you guys happen to know if a flipper zero could be used to impersonate something like yubi-key? and how would you go about it?

@cyberghost could it, yes ... is there a point? no

@cyberghost if you want to learn more about OTP and how the "secret" is used to generate one time keys it would prob be worth reading through the following RFC: rfc-editor.org/rfc/rfc6238

@CaffeineAddiction I don't think the only entities able to clone a Yubi-key would be three letter agencies.

@brynk That's a ChatGPT answer (and is also very wrong). I just flagged it now.

this may be a noob question, but what form does the "secret" take, and how is it stored in the key so that it is not accessible? is it physical?

@cyberghost Depending on how it's implemented, it could be OTP (one-time programmable) fuses, or it could be flash or EEPROM programmed in, but without the ability to reprogram it. There's also PUFs.

if it is stored in OPT fuses, how are the fuses set, or "given there value" ?

@cyberghost They're fuses, so they're set by burning them out during programming in the factory.

They're just microscopic. I think each logical bit probably uses two fuses with 10 meaning 1 and 01 meaning 0, and the default state being 11. That would ensure that any attempt to rewrite it would fail, even though it's still possible to burn out a fuse (change a 1 to a 0). But a Yubikey may just as easily use good old fashioned NAND (or NOR) flash, with a single OTP to indicate write-protection.

@forest thank you

@forest how about read protection?

@cyberghost Depending on how it's implemented, it could be burned into the microcontroller itself, so even if you remove the potting and expose the chip, you couldn't simply read from it manually. A lot of microcontrollers, even lowly 8051s, have the ability to both write-protect and read-protect internal values.

So essentially the value can only be accessed in the microcontroller, by the microcontroller. The only way to access it otherwise would either be by performing glitching attacks to put the IC into some unstable state where you can get it to do what you want, or decap it and analyze it under a powerful microscope.

@forest but this then not beg the question, that if the computer can get SOME value from the key, can not software the impersonates the key reader? please tell me if i'm making no sense.

@cyberghost The microcontroller may not allow you to read out the key directly. It may only allow you to perform certain operations on the key.

@forest like what operations? and what/how does the computer get the value from the key initially?

Operations such as signing. And the if the microcontroller contains the key itself, then it can perform operations on it. For example you may be able to ask the MCU to sign an arbitrary blob of data.

By computer do you mean the host that the Yubikey is plugged into? Or the chip?

the host its pugged in to.

There's an API that is defined by the driver and the USB device. The computer sends some command to the Yubikey, and the Yubikey's MCU handles the command.

So the computer itself never actually gets to see that key. It's not unique to Yubikeys either. TPMs contain an EK (Endorsement Key) that can be used for signing, but cannot be directly read from the TPM. Its purpose is to allow a TPM to prove that it is legitimate and not emulated or fake (assuming no one has compromised the hardware and stolen the EK, but TPMs are designed to be resistant to physical attack).