A list of journal papers being presented. Personal opinion though, most of the presentations have way too much detail - not sure what the main points really are.

Seems to be some database

Accounts for fault-tolerance by some.

Attestation includes querying of an Internet Attestation Service (IAS) to validate enclave creation in a distributed system. Solution to use local attestation as an intermediate attestation service.

Too many details in the presentation... this is what is the main point?

Comments:

1. XK: Local attestation every time an enclave created, is that particularly significant? Reply: Not really.
2. XK: Keys need to fit in the enclave memory. Can this database handle it?

ShieldStore is a hash-based key-value store designed for SGX. Mitigate SGX limitation of excessive paging in and out of enclave.

1. Baseline: Hash-based key-value store in enclave memory, server-side encryption.
2. ShieldStore: AES-CTR encryption for all entries in the same hash table bucket.

Some optimizations include: (1) use of extra heap allocator to avoid costly enclave exit, (2) MAC bucketing to avoid overhead of MAC accesses via pointer traversal, (3) store key hint (hash of plaintext key) to reduce cost of searching encrypted keys.

Performance comparisons with Baseline, GrapheneSGX, ShieldBase, ShieldOpt.

Speicher as a related work.

Comments:

1. XK: Is storage of unencrypted key hash an issue? 256 values for 1 byte key hint, can construct histogram of data...? Can leak data.

This group has the best introduction so far for KV store. Challenge is to extend trust to "untrusted and persistent" storage while ensuring security properties are preserved in a stateful manner at all times, e.g. even after outages.

1. Limited EPC size: Allocate MemTables in untrusted memory
2. Untrusted storage: Redesign LSM data structure to extend trust to storage media. Full Memtables are flushed to disk as SSTable
3. Expensive I/O syscall: Designed new I/O mechanism for shielded execution leveraging storage (smth)...? SPDK uses zero-copy I/O and some adaptive mechanism...?
4. Trusted counter slow: Designed asynchronous trusted counter for throughput and minimize wear-out.

Honestly I have no idea what they are talking about.

End-to-end encrypted filesystem. Problems when doing word search, got search access pattern leakage on word level. ORAM based solutions are not sufficient.

DORY authors looked at real-world usage, and came up with two requirements: (1) Linear search performance still okay, (2) distributed trust and trusted domain compromise impacts.

DORY uses Bloom filter: either answers element not in set, or that element may be in the set. Rather than a bitmap that contains every word, words are hashed and masked off the bitmap.

Proposed solution to mitigate search access pattern attacks, by using distributed point functions using different keys (a bit like secret sharing, but for encrypted keys...?). Master server will hold version numbers, which clients can then use to query replicas - functions as

$0.06 per user per month under usage assumptions. Highly practical to implement.

Comments:

1. XK: Does DORY have a rigorous proof for obliviousness, etc.?
2. XK: Requirements from the surveys of the companies, how is revocation implemented? Reply: Older keys are stopped from updates (though can still read). Newer keys are distributed to clients - new keys are only used when an operation is triggered by the user.
3. XK: Why semi-honest DORY performs better in latency as opposed to plaintext search? Reply: Bloom filter is compressed.