| 17 Jul 2021 |
 Mic92 (Old) | In reply to @andi:kack.it
Mic92: are you aware of a password manager that uses pkcs11 and isn't using GPG? Age is still not able to do that IIRC. No. What praticial security would it provide for users though to use TPM in this case? | 04:50:08 |
| Mic92 (Old) | Right now you type in a password to decrypt a symmetric key. With TPM i guess you would type in a key to unlock the TPM, which unlocks your symmetric key fro the password? | 04:50:56 |
 andi- | In reply to @mic92:nixos.dev
Right now you type in a password to decrypt a symmetric key. With TPM i guess you would type in a key to unlock the TPM, which unlocks your symmetric key fro the password? The key never exists in memory and the TPM could ensure that the device-specific secret for the password manager only ever works on this machine when you boot a trusted system (your bootloader, kernel, ...). | 07:58:27 |
| andi- | So the boot (+password) would unlock the TPM and then each and every password you'd decrypt using the TPM instead of a derived key in memory. | 07:59:04 |
| Mic92 (Old) | Ok, for device specific credentials this might be helpful but not the classic password manager that is synched across devices. | 08:01:07 |
| andi- | Why not? Right now I encrypt my pass database to plenty of GPG keys. One per device and the one on my yubi key | 08:02:19 |
| andi- | IMHO it would just be one more key I encrypt things for | 08:02:42 |
| Mic92 (Old) | An attack on the password manager would not look much different if an TPM would be involved I would say | 08:04:45 |
| Mic92 (Old) | Passwords need to be at some point in memory | 08:05:43 |
| Mic92 (Old) | It's different when you use the yubi key to authenticate remotly against a different system. | 08:06:15 |
| Mic92 (Old) | Than you never need to have the key in host memory | 08:06:32 |
| andi- | My threat is more about local code execution stealing keys | 08:09:46 |
| Mic92 (Old) | The key for what? | 08:11:03 |
| Mic92 (Old) | A second use case for TPM would be second factor auth | 08:15:48 |
| Mic92 (Old) | Also interesting: https://github.com/mtth-bfft/tpm-otp | 08:18:28 |
| andi- | In reply to @mic92:nixos.dev
The key for what? The key for the passwords. | 08:47:47 |
| Mic92 (Old) | In reply to @andi:kack.it
The key for the passwords. It seems like a small win in security for an increased complexity, since the passwords itself are still in plain | 08:48:57 |
| andi- | Yeah but it defeats all kinds of offline attacks on my password database | 08:49:24 |
| andi- | you can use my entire disk and still have no way to decrypt my passwords. Not even if you also have a memory dump. | 08:49:38 |
| andi- | You only obtain what you can observe me requesting. | 08:50:02 |
| Mic92 (Old) | I can imangine for most people the risk of loosing access to all their passwords is higher when their hardware breaks than the added security. | 08:51:56 |
| Mic92 (Old) | * I can imagine for most people the risk of loosing access to all their passwords is higher when their hardware breaks than the added security. | 08:52:18 |
| andi- | I would only loose access to keys on that machine and not all my passwords. | 08:52:50 |
| andi- | which is a perfectly acceptable risk for me as I can still use my YubiKey to access passwords (or another device with the same scheme). | 08:53:32 |
| andi- | In reply to @mic92:nixos.dev
Also interesting: https://github.com/mtth-bfft/tpm-otp This looks like it wouldn't go well with other TPM applications as they try to manage the TPM directly and write to random nvram positions. | 09:17:56 |
 @grahamc:nixos.org |
Corrected a problem which generated improper hash values on 16 bit machines
| 23:34:21 |
| @grahamc:nixos.org | damn this file has a LOT of history | 23:34:58 |
| 18 Jul 2021 |
| @grahamc:nixos.org | okay andi- I was maybe predictable wrong about the rvram | 00:40:08 |
| @grahamc:nixos.org | to r/w space you have to preallocate a chunk with nvdefine, and it gives you an "NV Index" in response: | 00:40:49 |
| @grahamc:nixos.org | [nix-shell:~]# tpm2 nvdefine -s 1
nv-index: 0x1000000
| 00:40:50 |
