CVM-IO Protection Motivation

[enterJazz]

As Dimitra pointed out, stronger motivation of the protection aspect would be beneficial to the work:

• From my understanding there is also a conceptual impact, i.e. the security guarantees you want to extend to the I/O, right?
  • Try to find a strong motivation for this because if you convince them that this is necessary and cannot be done (efficiently), then you already have a strong case
  • Compare your preliminary numbers with a naive design of the CVM that would extend the same properties as you do now. If you beet them significantly then that is also good!

[enterJazz]

Also, Julian had some interesting comments for CVM-IO protection, with which we could flesh out the protection design:

Julian:

Q: Could you explain how the problem/solution compares to existing data sealing functionality of SGX for example?

S: As already mentioned it is probably beneficial to accomplish as many protection goals as possible at the same time. I would suggest you have a look at AES GCM encryption. It is a well established algorithm that provides confidentiality, intergity & authenticity. Additionally it also allows to add associated data which could be helpful for managing counters to freshness.

My response:

Q: Could you explain how the problem/solution compares to existing data sealing functionality of SGX for example?

A:
SGX Sealing:

• how do we persistently store and provide SGX protection guarantees to individual secrets
  CVM-IO

• how do we extend CVM Storage IO to have higher performance and apply the CVM guarantees to storage IO data

• SGX sealing and cvm-io both aim to apply the same protection guarantees to certain data

  • SGX sealing has the advantage of directly using the sealing key- this is something which we would ideally also like to use with cvm-io

• however: cvm-io aims to apply the guarantees to 'disk-size' storage IO data ; adding transparent encryption

• SGX sealing is for the protection of individual secrets; hence , it requires the use of the SGX API ( no transparent protection ) and is not built for high performant use cases ( no large IO data streams )

• as such, CVM-IO is a kernel modification; while sgx sealing is not

wrt aes-gcm:
thanks for the comment; we actually use this algorithm for integrity- it is one of the ciphers we can specify in dm-integrity.
I guess in order to achieve freshness, we would need to 'only' seal the counter (if stored on disk, could be replayed).
So we could for instance use the sgx sealing mechansim for the counter, providing freshness- and aes-gcm would provide us all the other nice features. sealing mechansim for the counter, providing freshness- and aes-gcm would provide us all the other nice features.

TL;DR
We have replay protection if we use aes-gcm and protect the counter with CVM extension keys

[enterJazz]

Broad idea of AES-GCM use:

1. figure out how dm-integrity uses counter -> does it already provide replay protection?
2. if no: how can we add metadata to include a mapping of counter value to sector, to prevent replays ( detect via counter )
3. How can we use CVM extensions to secure counter? e.g. use SGX sealing to store counter securely

We can then have all CVM protection guarantees for the data!

[enterJazz]

We orignally also had the idea for varying performance.
If we figure out how to use some CVM-backed mechanism for a secure counter, we could still have trade offs with regards to how often we flush the counter.

[enterJazz]

To discuss w/ Dmitrii

• How to store secure counter via CVM extensions
  • How can we use the secure counter ( will be something like store AES-GCM counter I think )
• Which performance trade-offs can we make ( e.g. how often to flush counter )