TPM is fine, but you need to set a PIN to unlock the TPM. If you have a TPM without a PIN, somebody can just swipe the whole machine. PIN guesses are rate-limited by the hardware itself, so the PIN can generally be faster and easier to enter than a complex passphrase without compromising security.
IMO: TPM+reasonably random PIN offers comparable security to a strong password without a TPM, and better security than a weak password without a TPM. I prefer TPM+PIN since it's easier to enter 5-6 digits at boot versus a big complicated passphrase, but it's personal preference. TPM without a PIN is pretty useless though.
Isn’t it one million?
I agree that for the user who would pick a secure passphrase, it's comparable security either way and thus really comes down to preference. I like tapping a quick PIN on the numpad rather than typing out a passphrase, but I can definitely see the advantages to the passphrase approach: you don't have to depend on a piece of hardware specific to the machine, and the attack surface for a potential backdoor is a lot smaller, especially if you're using FOSS full disk encryption software like Veracrypt.
what happens at lockout?
Sure, the door is locked, but it's still very easy to open.
Back when I worked at MS, a PW was required on boot to deencrypt the drive.
I am honestly shocked that isn't the default for bitlocker. But then again it does require people to have a unique bitlocker PW, and if they ever forget it, everything on the machine is gone for good. (Which I've actually been bitten by, oops!)
I am not sure if it was the same system, but at a company I worked for we also had a boot password for bitlocker. People would sometimes forget it or bitlocker would somehow corrupt itself. IT was usually able to fix it though. I believe they were able to print out some kind of longer master password that could be used to unlock the machine.
(It would be nice if MSFT would do with Bitlocker recovery keys what they do with EFS recovery keys, and encrypt them with a public key. At that point popping Active Directory wouldn't be enough to get Bitlocker recovery keys-- you'd need a private key that, hopefully, was stored offline or in an HSM.)
So ideally you'd just get your recovery key and store it someplace well protected like a safe or a password manager.
Even though it decreases security substantially, they can still use lots of fancy words in the technical description, and only someone with knowledge in the field will understand how most of it is BS.
manual PIN entry IS the default for BitLocker, and the article states this.
Now TFA says it took 30 minutes and that's within the timeframe of an "evil maid attack".
If we take the same 30 minutes, then it's doable to: dupe the SSD and install a physical keylogger between the laptop's keyboard and the laptop's mobo, put back the laptop in place while looking like nothing happened. Then on the next login, when the person enter his password to decrypt the SSD, have the physical keylooger emit (radio?) the password.
Some may say it's science fiction but in TFA in 30 minutes they opened the laptop and hooked an analyzer to the TPM.
I guess what I mean to say is: it's hard to be safe in the face of an evil maid who has 30 minutes of access to your machine.
Is that an unreasonable burden on people?
I currently work from home.
Habits are important. I also put on my parking break every time I turn off my car!
So, IMHO, not an unreasonable burden!
I feel like since I'm on the security team, I should find a non-exploit method to actually resolve the policy failure.
...and now I have a project for this weekend.
The naive approach is to look at device ID, but article already talks about copying identification data, and the rest of USB descriptor is trivially copyable as well.
Is the system going to have a rule like "mouse moves same amount of pixels with equally spaced pauses"? But what if they randomize motion commands and intervals between them?
https://docs.microsoft.com/en-us/sysinternals/downloads/proc...
https://docs.microsoft.com/en-us/sysinternals/downloads/proc...
There is no device ID, process ID or binary to match.
If they are stuck on that policy, they should give you a smart card/yubikey heck even a fingerprint reader (You can't rotate these :-p ) to unlock your device.
You will just end up copying and pasting it around. I'd rather avoid that as there's many ways to copy out your clipboard with Javascript or a malware payload that somehow got onto your host.
I hope they also have a 30 day password expiry policy as well. Dont want users to get too comfortable with their password.
Even with a 12 password policy I see most people just using 'MyP@ssword2021', so I guess with 64 characters most people will just use 'MyPassword(012..9){6}'
https://www.my1login.com/resources/password-strength-test/
Along with this:
https://www.random.org/strings/
and I discovered that apparently, a 7 character password of random chars that includes a 0 (zero) is really hard to crack!
I wont be doing that though for my own passwords but it was interesting none-the-less.
I wouldn't call it a burden.
I always switch off the biometric access of any machine, so you can save yourself the hassle of cutting off my thumb or trying to unlock a device when I am asleep.
Though Idunno how happy that'll make you.
The idea is that basically very few keyboards have an F15, let alone applications that rely on the F15 key.
This is not a good look, but if that's how you want to play the game of lying to your employer, fine with me!
If you want to lock your PC you need to lock it.
i thought the whole point of hardware oracles like TPMs was to avoid loading a PSK into RAM, making removable RAM sticks simple non-destructive attack vectors.
I.e. it's not uncommon for you password to be used to decrypt an encryption key which then lives in RAM and is used to decrypt data. So as long as you "just" have a TPM then it's not preventing that attack wrt. full disk encryption. For it to do so you need either a secure module on you hard-drive (and trust that module) or need to pipe all disk I/O through the TPM (and hope it's fast enough). Through there are (should be?) some hybrid models.
Anyway you can combine both a TPM and a external password (in different ways depending on how the encryption is done).
One additional common reason against using a TPM for full disk encryption is if you want to make data recoverable even if you TPM (motherboard/cpu) fires itself.
I would say for most companies the benefits of requiring a password (or better HSK + PIN) for boot instead of only a TPM are outweighing the risk of a RAM removal attacks. Especially if combined with intrusion detection and short times between suspend and full (non hybrid) hibernation.
It's a feature of modern server CPUs which have a AES-128 encryption engine directly embedded in the memory controller (and combine that feature with virtualization, i.e. different encryption keys for different VM).
> does LUKS on Linux keep the keys in the processor's SME all the time?
The LUKS mater key is kept in the Linux Kernel Keyring and while I'm 90% sure that at least when accessing a encrypted partition it's in RAM.
I also would guess that the large majority (all?) of on-the-fly disk encryption software suites/libraries have this problem.
The only way not to have this problems would be to pipe all disk (data) I/O through a fast encryption engine connected to the TPM. And as far as I know this is not part of the TPM feature set(1) (the fast, high throughput part). But then DRM has kinda similar requirements, so maybe I'm wrong.
Through IMHO most companies and people in most situations don't have to worry about RAM extraction attacks as they are way to complicated and brittle, especially if combined with e.g. case intrusion detection and suspend-to-disk automatically after some time. Through as far as I remember it played a role in some "police extracts chats from locked iPhone" cases.
(1): TPM is besides some features around attestation and early boot mainly a from of Hardware Key Store, so e.g. if you use it to sign a blob you don't pipe the blob through the TPM but you (cryptographically secure) hash the blob and then only sign the few bytes long hash by passing it through the TPM. Similar encryption is normally done by doing a AES encryption of a blob and then encrypt the few bytes long AES key using the TPM. But again, I'm not a expert in that area and thinks might have changed, but I guess they haven't (I would be surprised).
i think passphrases are better for any situation where you might be typing them in multiple times a day.
since you can use all lowercase letters, it makes it much quicker than having to press the shift key for capitals or symbols, and you can make up for the lack of those characters by using a longer words/passphrase
https://www.useapassphrase.com
on top of that i usually spend a bit of time choosing words that are quicker to type. like words that have letters that alternative between each hand seem to be quicker than typing a word that's only on one side of the keyboard. avoiding words that have double letters for the same reason. making sure the end of one word and the start of the next are typed with different hands. choosing words where most of the letters go in the direction of your pinky to your index finger if possible
If you insist on choosing words, you must compensate for this by choosing more words; i.e. having a longer passphrase. Exactly how many bits of entropy you lose by manually choosing words is hard to say without knowing your exact criteria for choosing, but it can be calculated exactly if these are known.
We've got a few parameters to work from here:
- By a Google Books estimate from some years back, there were roughly 140 million books ever published. That's been going up by ~1--5 million a year for the past decade or so (only about 300k are "traditionally" published). See Bowker.
- If we limit ourselves to a reasonable canon -- the 100, or 1,000, or 10,000 most-frequently-read books, that number goes down a lot. (Twenty years ago when I had this conversation at work with a user, I said "a phrase from Alice in Wonderland isn't obscure enough. They'd chosen lines from "Jabberwocky", and no I'd not run a cracker.)
- A typical book runs about 250 pages, at about 500 words per page, and about 10 words per sentence. That's about 125,000 words, or 12,500 sentences, per book. Even assuming no sentence ever repeats (they do), that's "only" about 1.7 billion sentences in all published books. For the top 10k, it's only 125 million, the top thousand and 100 are 12.5 and 1.3 million respectively.
Computationally and cryptographically, those are small keyspaces.
Oh: and many of those books are scanned and OCRed. ZLibrary (from which LibGen and other sources pull) has over 8 million books (http://zlibraryexau2g3p.onion/) --- approaching that of a substantial university library collection (The University of California library system has 40.8 million print volumes across 10 campuses and 100 libraries, with 4.3 million digitised in HathiTrust: https://libraries.universityofcalifornia.edu/about/facts-and...).
Randomly-gathered words (EFF Diceware or xcdpass, see https://www.eff.org/dice or https://pypi.org/project/xkcdpass/) are robust --- we don't just combine words at random typically. And as mentioned, joining phrases from different books should be reasonably memorable (combinatorics work in the defender's favour).
or tell microsoft to use tpm 2.0 features if they force us to use a tpm v2?
Using a tpm without such features in order to improve a disk encryption setup to the same or above that of a password is difficult and full of problems, and there are some distinct drawbacks. There is a reason why Microsoft bitlocker is primarily intended to protect a users home directory after they have provided a password. If the pin to the tpm is in clear text on the disk, and all the tpm is doing is converting that pin to a password to unlock the disk, the benefits are generally small.
How might I handle the situation where a given device has been stolen, attacked and returned, without my having observed it happening?
https://blog.elcomsoft.com/2021/06/breaking-veracrypt-obtain...
Disk encryption is generally in XTS mode, and not authenticated. That’s not limited to veracrypt.
https://magazine.atavist.com/category/Mastermind/ Recommended reading!
https://en.wikipedia.org/wiki/Comparison_of_disk_encryption_...
> [...] it appears that OpenZFS encryption is far stronger than LUKS or VeraCrypt encryption.
> LUKS and VeraCrypt use the XTS mode of encryption, which is not authenticated, and is vulnerable to some limited recovery of information when an attacker can have access to the encrypted data at different times. On the other hand OpenZFS encryption is authenticated and at the state of the art. Also, you should take care to disable compression when encrypting with OpenZFS.
This is new to me, why?
Random binary data doesn't compress very well, sometimes even negatively.
There have been what’s called “compression oracle” attacks on SSL with compress then encrypt scheme, see CRIME
https://en.m.wikipedia.org/wiki/Oracle_attack
An attacker could inject known plaintext to an unknown source and observe the size of the ciphertext. If the size doesn’t change much, it means the chosen plaintext is correlated with the source. Several variants exist.
Compression is often not recommended in VPNs.
TBH, with whole-disk encryption I would not worry too much about this attack (the threat model is almost always theft where repeated observations of the cryptext after being modified by someone with the key are not practical), but it was core to a lot of vulnerabilities that basically forced TLS-level compression to be almost universally disabled.
There are several different products on the market, and a variety of ways that native solutions like Bitlocker can be configured.
Either use the OS-provided solution (Like LUKS, FileVault, or BitLocker), or use a cross-OS solution like Veracrypt <https://veracrypt.fr/>.
Secondly, to avoid the problem in this article, you should have an external password necessary to unlock the drive; not a TPM. This is, of course, not what most people do, since typing in passwords is tedious.
However, if you mostly need to boot up the laptop when connected to a specific network (e.g. on company premises), and it’s acceptable to require a manually typed password when the laptop is not present at that location, and if you use a Debian-based OS, there is a solution! Shameless plug: https://www.recompile.se/mandos