<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den mån 21 nov. 2022 21:20Jerrold Leichter <<a href="mailto:leichter@lrw.com">leichter@lrw.com</a>> skrev:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> I've been wondering how many of the current OS/page table and file<br>
> system protections can be theoretically implemented via cryptography.<br>
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?<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
*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.<br>
<br>
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.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">I've posted the idea a few times, and here's response with a proposed scheme based on ECC;</div><div dir="auto"><br></div><div dir="auto"><a href="https://www.reddit.com/r/crypto/comments/wijktp/how_google_played_with_bad_cryptography/ijcerj4/?context=5">https://www.reddit.com/r/crypto/comments/wijktp/how_google_played_with_bad_cryptography/ijcerj4/?context=5</a><br></div><div dir="auto"><br></div><div dir="auto">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) </div></div>