Hacker News Reader

Comment by teddyh | Hacker News Reader

The first step is to actually encrypt your drives. Far too few people and places even do this step.

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

View on HN

> 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.

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.

You could get almost the same benefits and none of the drawbacks of a TPM by using a password hash function with enough complexity to inherently limit the number of checks possible per second.

I can't think of a key derivation function which would reliably make, say, a 6 digit PIN tough to crack while also not painfully impacting user experience waiting for the machine to unlock at boot. For a 6 digit PIN it's only 10 million iterations to exhaust all possible options, and the attacker gets to parallelize their guesses if they're willing to throw hardware or cloud resources at it.

I did say “almost”; one of the requirements is that you have to set an actually secure password; i.e. not a 6 digit PIN.

Totally! And for a user that knows the importance of a secure password, that's fine. But the average user in an organization picks terrible passwords. A random 5 or 6 digit PIN generated by the IT department (to avoid the user picking their daughter's birthday) used to lock a TPM is generally easy to remember and secure, especially if a lockout policy is set on the TPM.

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.

> especially if a lockout policy is set on the TPM.

what happens at lockout?

Recovery with the escrow key held by IT, typically.

> For a 6 digit PIN it's only 10 million iterations to exhaust all possible options

Isn’t it one million?

Er... yep. Oops. That's embarassing, don't know how I made that mistake.

Pins vs passwords are not something I have seen much discussion on in the software security space. The only general criticism I have heard of pins is that people tend to pick dates when asked to use a random 4-6 digit sequence, which makes them often trivial to guess. Personally I have always leaned towards the now classic xkcd method of combining 3 random words, which can often lead towards funny and memorable passwords with great length. The only major drawback is that they take long time to type, is a pain with touch keyboards, and are prone to miss clicks in low light conditions.

Exactly. Using _just_ TPM is like locking the front door to your house, and leaving the key in the keyhole.

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!)

Care to desribe the experience, and what was lost to you?

Now that I remember, there is a separate key stored by the corporation that can also unlock the drive.

It seems like it'd be possible to have a separate recovery key stored by the company in addition to the regular password.

That's how my employer does it but it's for less than a hundred devices so we just provide security the key after turning on FileVault.

I don't recall whether or not it's the default, but Bitlocker can do this on domain-joined machines-- they get automatically backed up into Active Directory where they can be retrieved from the computer account's properties (or there's a tool in RSAT that can find them).

> 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.

That would probably be the recovery password, which is a long string of gobblydigook. In corporate environment, the recovery password is backed up to the user's Azure AD account and logged by the configuration manager (like InTune, probably 3rd party ones too).

Commonly machines will be configured (via Group Policy) to store their Bitlocker recovery keys in Active Directory (where they are readable by only privileged users).

(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.)

> I am honestly shocked that isn't the default for bitlocker.

manual PIN entry IS the default for BitLocker, and the article states this.

It isn't, and you are misparsing the sentence in the article (it is saying the configuration as it was is the default, but describes it through what it's not, which makes the sentence a bit confusing) - look at the linked Microsoft documentation for confirmation.

My guess is that this is more "user-friendly".

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.

Bitlocker actually has multiple keys. There's one key to encrypt your data. There's a volume master key that encrypts the data encryption key. And then there are zero or more key protectors for the volume master key. One of those can be the TPM (or TPM with PIN), one can be a long password, one can be a recovery key (IIRC 48 decimal digits), and I believe there are other options as well. Each one is independently capable of decrypting the volume master key, which in turn decrypts the data encryption key, which in turn decrypts the data.

So ideally you'd just get your recovery key and store it someplace well protected like a safe or a password manager.

That's what I do: LUKS and a (complicated) password needed to decrypt the drive.

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.

My company requires a password every time laptop wakes from sleep.

Is that an unreasonable burden on people?

It depends. Can you turn off auto-sleep?

My corp laptop auto-locks the screen (if that's what you mean), but can also be unlocked by biometrics, but only if it's already on. (And only for a limited time; I think after a week, the password is required again.) If the laptop is booting fresh, the password is required.

I wouldn't call it a burden.

> but can also be unlocked by biometrics

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.

I guess anyone able to do either of these things could just torture you into surrendering your password, though.

I guess you could hope for their decency to cut off bits only after they've killed you. Combine that with their possible (probable?) stupidity to assume you have biometrics enabled, and they might kill you without even asking for any password, so you'd die secure in the knowledge that they'll never crack your data.

Though Idunno how happy that'll make you.

Don't turn it off, get something like the little Caffeine application. It simulates an F15 keypress every 59 seconds to keep it awake.

The idea is that basically very few keyboards have an F15, let alone applications that rely on the F15 key.

Note that if you're caught doing this by IT, you may get fired for willfully breaking policy. It is quite easy to detect.

There is plausible deniability. Just say my touchpad is malfuncioning and sometimes moves the cursor.

In other words, you didn't report a touchpad malfunction that was interfering with obvious and clearly stated security policies, and allowed the malfunction to interfere with your work for days/weeks/months without seeking assistance from IT?

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!

No, because the touchpad malfunctioning has no impact on a security policy whatsoever. Not even work possibly.

If you want to lock your PC you need to lock it.

As I mentioned above, the SOC team can detect the exact process ID for these app really easily. No plausible deniability.

What do you mean by process ID? A PID seems like a useless bit of information. Now an app bundle or process executable checksum... Seems more useful. But couldn't you build the app from source and add a but of random data into the executable?

Yes it's better to have a hardware fix, like a USB stick that moves the cursor regularly or sends a key press, or even just put your mouse on top of a watch that has hands.

I mean.. There's also OS APIs to prevent sleep that are probably even better suited.

Oh boy, I see the potential for very weird bug reports that will be fun to debug when you forget that that thing is active (or another user is using the computer).

I just 3D printed a little clip that holds the scroll lock key down. Or, there’s always the mechanical or electronic mouse jigglers you can buy off of Amazon.

Windows Powertoys has an Awake applet that does the same thing nowadays. Same thing as in, has the same effect of keeping the machine awake, that is; dunno how it does it, if it's simulating a keypress or something else.

Depends on what the sleep time is. If it’s after 1 minute, yes. After 10, I think that’s fair.

As someone currently fighting with IT because of their 64 character password and a Global Policy for a 5 minute timeout, I would be so happy to have 10 minutes.

https://ericdraken.com/usb-mouse-jiggler/

That's a great solution, which all of our developers are exploiting.

I feel like since I'm on the security team, I should find a non-exploit method to actually resolve the policy failure.

Perhaps the mouse jiggler IS the answer. Not to solve your own plight as a result of the policy by using one, but to illustrate what lengths people are going to in order to mitigate the undesirable effects of the policy.

Agreed man. If developers are resorting to this the policy is wrong, not the developers.

Note most SIEM's (your SOC team) can detect this (not by default as far as I know).

Depending on the desk, a downward facing bass speaker and a raspberry pi+webcam that detects your presence could do the job while maintaining an airgap (assuming you're using a mouse, not a trackpad).

...and now I have a project for this weekend.

Genuinely curious: how would they do this?

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?

Probably they are lot more advanced then they used to be, but yeah, checking for device ID / Process ID in combination with binary (.exe) and location. Typically these Programs are portable (no installation required, just run the .exe.) and on a corporate machine there are not many places to store it (typically within your user profile). Programs like "Process Explorer" and "Process Monitor" will give a great amount of detail on processes which can be used for detection.

https://docs.microsoft.com/en-us/sysinternals/downloads/proc...

The linked device is a hardware mouse jiggler, not software. USB devices are easy to imitate, so such a jiggler could be programmed to look like, for example, last year's most popular wireless mouse.

But this a physical USB device which presents exactly the same interface as a real mouse, likely up to the device descriptor.

There is no device ID, process ID or binary to match.

Well, my siem probably wonders why I randomly and repeatedly mash the F15 key through the day sometimes (keeps teams status as "Alive and Present")

64 characters? Why would they do that?

I assume there was a bet involved.

64 character password... no. I get it for password cracking purposes but they should make it hard to ever move to that stage in the first place.

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 don't understand these insanely long password requirements. How are they more secure than say a strong 8-char 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}'

IIUC, 8 characters is too short now. You should use at least, IIRC, 12 random characters. Or a multi-word passphrase of equivalent entropy.

Yesterday I was playing with this:

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.

You can have a static password on a yubikey - tap and go to log in - https://www.yubico.com/resources/glossary/static-password/

I hope they also have a 30 day password expiry policy as well. Dont want users to get too comfortable with their password.

Lid-closed or inactivity-sleep? Yes, absolutely.

No Windows Hello I assume? Either Fingerprint or Face?

I lock my laptop every time I stand up from my chair.

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!

> you should have an external password necessary to unlock the drive; not a TPM.

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.

It's complicated.

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.

Out of curiosity and to ameliorate my ignorance -- does LUKS on Linux keep the keys in the processor's SME all the time? How easy is it to just encrypt everything in ram?

> How easy is it to just encrypt everything in ram?

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).

TPMs aren't fast enough to do disk encryption at anywhere near the speed of modern storage, so a TPM-based FDE key is simply something that the TPM decrypts and hands back to the OS.

You'd have to build something like the Apple T2 chip.

> since typing in passwords is tedious

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

This is a whole other topic, but if you are choosing what words to use, the words are no longer random, and your password (sorry, “passphrase”) is no longer as secure as mere word counts might lead you to believe.

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.

Pick 5 random words from the top 10,000 most common English words, and you have just a bit more entropy than a password composed of 8 random printable ASCII characters.

https://xkcd.com/936/

Let a machine, or dice, do that for you and avoid common pitfalls.

https://pypi.org/project/xkcdpass/

https://www.eff.org/dice

Is there a brute force list out there that tires all the words (from diceware lists) that people are more likely to choose, and in the orders that they would choose them, etc, first? Its does seem very hard to quantify how much you lose by cycling through passphrases until you get one that feels like you could remember it. Personally I just make very long passphrases, and memorize them to tunes of songs. Its good typing practice everytime I boot up. Three times wrong and you have to restart.

yea that's definitely something to keep in mind. i usually try to use a few different word generators and also throw in a random character somewhere or spell a word in my own way just to make it a bit less predictable

We're already at the point where any phrase from any book ever written is probably insufficiently secure. (Mixing phrases from multiple books might work.)

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).

> you should have an external password necessary to unlock the drive; not a TPM

or tell microsoft to use tpm 2.0 features if they force us to use a tpm v2?

If you know of tpm 2.0 features that have the disk encryption and decryption occurring in the TPM chip itself then please enlighten me. I have not heard of that.

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.

I find it interesting that because they used SPI sniffer, CPU memory encryption features would not have prevented the attack. Looks like all communications between PC components need to be encrypted

The key doesn’t need to be kept in the TPM. It just needs to be encrypted between the CPU and the TPM.

actually tpm 2.0 can build a secure communication channel to send the key to the cpu and thus makes that a unlikely attack. of course there are many more attack vectors, but this possible one can be prevented with a correct communication channel. https://trustedcomputinggroup.org/wp-content/uploads/TSS_ESA...

The biggest issue I have with TPM is that it's overly sensitive to the device configuration. Plug in an extra mouse at boot and I'm locked out of BitLocker (it asks for the recovery key). That's too dangerous for my data, at least for my personal use. VeraCrypt works better in that aspect.

BitLocker can be configured to be passphrase-only.

After taking a quick look at Mandos, I realized you might have some insight into how to solve something that's had me stumped for a while:

How might I handle the situation where a given device has been stolen, attacked and returned, without my having observed it happening?

macOS FileVault is also a good option for whole-drive encryption, as the hardware then requires the external password in order to unlock the drive to continue booting.

It's a sad state of affairs when Veracrypt is one of the top contenders for tools to use. We need a fresh batch of properly maintained privacy tools.

Feel free to recommend something else from this list:

https://en.wikipedia.org/wiki/Comparison_of_disk_encryption_...

https://security.stackexchange.com/questions/242427/is-nativ...

> [...] 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.

> Also, you should take care to disable compression when encrypting with OpenZFS.

This is new to me, why?

Encrypted data attempts to look like random binary data, generally.

Random binary data doesn't compress very well, sometimes even negatively.

OP said the other way around. We all know encrypted data does not compress well, but why would you need to disable compression when encrypting? Compressed data should actually be a smaller dataset hence encrypting it should be even faster.

In general, if the size is then visible after encryption, you can tell that the data, whatever is was, compressed well. This is information leakage, and can, IIUC, be exploited to surprising degrees.

This doesn't make any sense. Here you have a disk. It's compressed or not, doesn't matter, the size stays the same. Then you use BitLocker on it. Again, compressed or not, after BitLocker encrypts it, the size is still the same. Your point?

Like I said, “if the size is visible after encryption”. I don’t know if this is a huge issue with block device encryption in general, but then again, OpenZFS isn’t really only a block-device-level driver, is it? I would not be surprised to hear that OpenZFS somehow encrypts on some higher level than the whole block device.

Compress then encrypt opens up one important vulnerability: if an attacker can control a part of what you're encrypting (which they perhaps can on an average laptop drive, think a cookie in a webbrowser), and they can observe the size of the message after it has been compressed and encrypted, then with repeated attempts they can guess part of your secret and wait until the compression algorithm succeeds in matching part of their data with your secret.

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.

True, but you could compress then encrypt.

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.

Pretty much everything uses AES-XTS: BitLocker and FileVault do as well

Whats' wrong with Veracrypt?

Wasn't it originally written by that criminal mastermind hacker genius who probably is Satoshi?

That was truecrypt

Paul Le Roux probably isnt satoshi, but he is a very interesting person. The article series "The mastermind" goes into some depth about what he was up to:

https://magazine.atavist.com/category/Mastermind/ Recommended reading!

And VeraCrypt is a fork of TrueCrypt

This guy says veracrypt is tough, even tougher than LUKS:

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.

Veracrypt is not a contender for a commercial solution.

There are several different products on the market, and a variety of ways that native solutions like Bitlocker can be configured.

This is bad advice. You should use a PIN on your TPM and not a password protecting the drive header.

I don't think this is true, a decent password is as secure if not even more secure.

Reply on news.ycombinator.com