[Cryptography] Can crypto implement OS/FS protections ?

[Natanael]

Den mån 21 nov. 2022 21:20Jerrold Leichter <leichter at lrw.com> skrev:

> > I've been wondering how many of the current OS/page table and file
> > system protections can be theoretically implemented via cryptography.
> Well, let’s start simply.  You can certainly control *read* access by
> encryption (though there are limits to the protection - e.g., suppose I
> want to say that if you don’t have read access to a file, you can’t even
> tell if it’s been changed since you last looked).  But how would you
> control *write* access?  The obvious starting point is to require that the
> data proposed to be written be signed - but then what?
>
> o  The system can check the signature for validity before committing the
> new value.  But that’s ultimately not “using cryptography” - it’s just
> giving the OS (or the hardware if you want to embed such checks there, as
> certainly happens for main memory access) a more complex way to *decide*
> who can actually write.  If the OS gets the check wrong, maybe you can
> catch that when you come to read the data, but the original value is gone.
>
> o  The system just stores all offered writes, and it’s up to the reader to
> pick the most recent one that has a valid signature.  While this works, it
> doesn’t seem at all practical except in some very specialized applications.
>
> Note that blockchain writes are related to the first approach, where you
> need some distributed agreement to be able to add to the blockchain.  But
> the *agreement itself* - the enforcement of whatever policy controls what
> can be added - isn’t *implemented or enforced* by the cryptography, but by
> decision procedures that *rely on* the cryptography.  Break the decision
> procedures and, at best, the crypto will keep stuff that was supposed to be
> secret still secret.
>
> *Maybe* one could do something with homomorphic cryptography, where the
> “write” is a function implemented “inside” the cryptographic envelope?  I
> don’t see it offhand, but it could be.
>
> Without the ability to cryptographically enforce who has write access, I
> don’t see how you can get very far in implementing OS/FS protections.


You can't prevent writes using only math when you don't trust the
hardware/OS. The homomorphic "container" could just be substituted. And if
you're assuming an adversary that can mess with kernel memory then you've
already lost. But you can do a few things to increase safety on
partially/mostly trusted hardware.

You can create a scheme where the data in memory is only readable if it
passes a signature check for the correct public key, and otherwise gets
scrambled - the signed data is encrypted, and a variant of signatures with
"message recovery" is used to embed the encryption key such that it only
can be extracted if the signature validates for the pair of wrapped
message/ciphertext & public key. All reads apply this verification & key
derivation combination to then decrypt the actual data. If any piece gets
substituted then the derived key is wrong and the decryption output is
garbage. So a failed ACL check on write doesn't allow insertion of
malicious data, only scrambling / erasure.

I've posted the idea a few times, and here's response with a proposed
scheme based on ECC;

https://www.reddit.com/r/crypto/comments/wijktp/how_google_played_with_bad_cryptography/ijcerj4/?context=5

This still doesn't protect from faulty overwrites being possible. And if
both an overwrite with plaintext AND a naive read happens that completely
skip the check then no cryptography scheme can do anything to help. Maybe
if you could enforce it in hardware? (although in that case you could get
better performance with just a MAC check, preferably using capabilities
style tokens)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20221122/53f10ce3/attachment.htm>