Well Trump said it: "why it is we only take people from s**hole countries," and "why can't we have some people from Norway, Sweden, just a few? Let's have a few from Denmark."
They may not say "turn off bitlocker", but people definitely recommend backing up the recovery keys, and windows allows you to back up the key to microsoft because they know people won't actually back them up. Not sure if that happens by default, but they provide a variety of options for the recovery keys because there is definitely a non-zero chance you need them. There were several stories of this happening with the windows 10->11 upgrade push, where people were auto-updated and then scrambling to decrypt their hard drives.
The only way to protect against that is if a secure application boundary is enforced by the operating system. You can make it harder for other programs to uncover secrets by encrypting them, but any other application can reverse the encryption. I don't believe using the tpm meaningfully changes that situation.
I suspect that they do not actually contain the encryption key. It is more convenient if the disk encryption key is stored on the disk, but separately encrypted. You actually want to store the key multiple times, one for each unlock method. If the disk can be unlocked with a password, then you store the key encrypted using the password (or encrypted using the output of a key derivation function run on the typed password). If it can be unlocked with a smartcard, then you store a copy that is encrypted using a key stored in the card. When Bitlocker uses the TPM, it no doubt asks the TPM to encrypt the key and then stores that on the disk. To decrypt the disk it can ask the TPM to decrypt the stored key, which will only succeed if the TPM is in the same state that it was in when the key was encrypted.
The reason it's done this way is to allow multiple methods of accessing the disk, to allow the encryption password to be changed without having to rewrite every single sector of the disk, etc, etc. You can even “erase” the disk in one swift operation by simply erasing all copies of the key.
That is also required for any kind of key rotation to work, you're getting new key for a key, because alternative of using key directly would mean re-encrypting the whole drive when it changes and of course only having single one instead of multiple
Working backups are important regardless, but if you use a TPM then you’d better have your recovery keys somewhere convenient. I’m sure you can print them out and keep them in your wallet or something.
don't worry, ms pushes users to just put data on onedrive, they will start losing data far before machines actually die. We already had plenty of stories of that mess.
Everytime I have to upgrade my MB firmware it breaks bitlocker and I have to either use restoring keys from microsoft website or disable bitlocker encryption before the upgrade.
You cant reliably store secrets in tpm and expect it to work after an os update. Windows is using workarounds during windows update to avoid breaking bitlocker.
You are correct. Updating the firmware or the OS does not actually erase the TPM. What is really going on is that the TPM register holds a value that is like a hash. Each time you measure the system state you update the register with a hash of the previous value and the measurement. When you ask the TPM to hold a key you specify which register value is used to encrypt the key. Later when you use the key it will fail if the TPM cannot decrypt the key. This can only happen if the TPM register has the wrong value, which can only happen if someone has tampered with the system. But voluntarily upgrading the BIOS or the OS looks exactly like tampering.
The correct procedure is to unlock the keys, copy them out of the TPM, perform the upgrade, reboot to remeasure the system state, then finally store the keys back into the TPM.
Wouldn't you want TPM to brick the machine if the firmware was modified? If something or someone modified your firmware, do you want the TPM key to remain intact? Its something you need to be aware of when upgrading firmware, disable encryption that relies on TPM or make a backup copy of the key.
>or even by normal load from someone deciding to split a /8 prefix into /24's
If that kind of happening directly from load of added 25 routes it's quite hard to believe it.
# 10/8 prefix here only to show how to get number of new routes added.
$ sipcalc -n 24 10.0.0.0/8 | grep -c Network
25
$
BGP peering routing policies have then been for the good reason constructed in way that they expect advertisements "exact accept" with a prefix-list with that /8 prefix, because that's is expected when peering is agreed even when not explicitly stated by many. This expected best practice following goal to manage and prevent internet routing table being filled with superfluous routes.
But anyway, sudden change from /8 to 25 x /24 without first noticing your peers and giving them time to change that "exact accept;" to "orlonger accept;" is quite sure footgun if you don't know common principles of network management. But usually that kind of screwup blast radius is local mostly local only to that /8 prefix.
Not sure though how that could be technically avoided in BGP protocol or router control-plane (router OS config) design. Policy filters and best practices how to use them have been set for good reason. Not just to irritate and make things harder than they need to be. We certainly did not do that while I was still working.
Right, something else what could happen with that kind of sudden change is. If that peered had also other peers which had instead "orlonger" in place traffic would then switch to that, what could have some side effects like saturated links, slowness or even increased costs. Too bad, and may happen. But principle is that communicate your routing changes in good time before you actually make the changes. That will prevent most of this kind of problems ever happening to you.
Oh, my bad. How didn't I notice my mistake right away. That 25 is grossly wrong, I should have checked before using that. The correct line to get subnets is
Which increases significantly global routing table size of course. I apologise my mistake on that matter that I should have noticed before posting.
Anything else I wrote about changing prefix advertisement is correct. You should and need to communicate your advertisement changes in good time to your peers and let them time to make changes.
Most BGP peers have router filters in place. It's not 1996 anymore. I remember the days of logging into a Cisco connected to a Sprint T1 and seeing a coworker had fat fingered a spammer's route, sending it to null0. Oops. How did that happen?
Considering the routing table size has been increasing and IPv6 need anyone shouldn't be running global routing with gear not supporting RPKI any more, the routing polices and announcing those RIR they operate.
Many v4 prefixes in the ARIN region are legacy and don't support RPKI unless you sign the registration agreement. I have a legacy prefix and may eventually be forced to sign up.
type Error struct {
// Path is the Upspin path name of the item being accessed.
Path upspin.PathName
// User is the Upspin name of the user attempting the operation.
User upspin.UserName
// Op is the operation being performed, usually the name of the method
// being invoked (Get, Put, etc.). It should not contain an at sign @.
Op Op
// Kind is the class of error, such as permission failure,
// or "Other" if its class is unknown or irrelevant.
Kind Kind
// The underlying error that triggered this one, if any.
Err error
// Stack information; used only when the 'debug' build tag is set.
stack
}
reply