Viewing a single comment thread. View all comments

Gareth79 t1_izcgcxc wrote

It means the data is unreadable if you have access to the servers directly, eg. by stealing them physically, or by a low-level hack getting access to the filesystem. I don't know if Apple need the keys for any routine access, but they will be stored and handled separately and likely very securely.

2

happyscrappy t1_izch8es wrote

> It means the data is unreadable if you have access to the servers directly, eg. by stealing them physically, or by a low-level hack getting access to the filesystem.

You're seriously concerned about stealing drives physically?

And the data is not likely stored as files in a filesystem. But instead of a more capable database.

> but they will be stored and handled separately and likely very securely.

If they are employable on every use then they have to be at hand. You're thinking they can hack far enough in to get to everything on the machines but the keys?

1

Gareth79 t1_izclry6 wrote

Apple will definitely be concerned about physical server theft, yes. Virtually all modern cloud platforms use encryption at rest to protect against this.

8

happyscrappy t1_izdfckf wrote

> Apple will definitely be concerned about physical server theft, yes. Virtually all modern cloud platforms use encryption at rest to protect against this.

All data is encrypted at rest now. Because whether it is stored on SSD or HDD the data in encrypted by the storage device to whiten it. The question then comes where are the keys? For a drive the whitening keys are on the drive, you steal the drive you get the keys. So that encryption at rest does nothing for you.

So the question is does other additional encryption at rest you put on top do anything for you? It depends. If they steal enough drives they get your keys as well as the data. So the encryption at rest nothing for you.

0

Gareth79 t1_izdnln2 wrote

You appear to be talking nonsense.

4

happyscrappy t1_izeszqq wrote

No. I'm not.

They whiten data because if you don't, if the data has far more 0s than 1s (or vice versa) then it creates a local imbalance in charge level on the disk (or NAND sector). If the local imbalance is large enough it affects other data nearby (that's how magnetic fields work).

So as I said, all data is encrypted at rest now. So, as is nearly always the case for security the real question comes down to key management, not "whether it's encrypted".

E2E would mean that the keys are generated by the client each time it connects. And then presumably it is not written down (it better not be). So no one can steal drives and end up with the keys.

Is this the case for your idea of putting other encryption at rest on top but without E2E? Is it adding appreciable security?

1

qwerty12qwerty t1_izdb0zn wrote

I don’t necessarily think it’s at rest, doing so would exponentially increase your computing power. But it’s probably something like Windows a bit locker. Where the entire drive is encrypted when you turn it on, requiring a key to even boot. To steal a drive, the power would be disconnected. Or some other thing to trigger a shut down/require the key.

−2

Gareth79 t1_izdo06d wrote

Bitlocker encrypts when the feature is enabled, not when the computer is "turned on". Every read and write requires encryption/decryption of the data. It doesn't "exponentially" increase the computing power required, modern CPUs have AES acceleration: https://en.wikipedia.org/wiki/BitLocker

3

Volitank t1_izd4clg wrote

The accounts that read the data would likely have a method of utilizing the keys. I would assume a different key per account.

Authentication is handled separately from the database itself. A breach of a single database host, even as root, would not mean you're able to view the data in plain text or have access to the keys.

It could be decrypted in stream. User authenticates into the system, it then grabs the encrypted data in the database, decrypts it outside of that host using their key and sends them the decrypted data.

Of course I don't know Apples infrastructure exactly but encryption is definitely not useless in this regard.

1

happyscrappy t1_izdf60m wrote

> Authentication is handled separately from the database itself. A breach of a single database host, even as root, would not mean you're able to view the data in plain text or have access to the keys.

A breach of a single database host isn't even going to tell you who the data is associated with.

> It could be decrypted in stream. User authenticates into the system, it then grabs the encrypted data in the database, decrypts it outside of that host using their key and sends them the decrypted data.

Yes, it could be. It hardly matters. Unless it is E2E the key to decrypt it is there on the host that sends it. They just compromise that host instead.

1