CS161: Computer Security

CS161 2022 fall, project2, 实现一个多用户文件分享系统。 以下是我的设计文档。

Threat Model

Assume that all adversaries know my source code.

Datastore Adversary

Datastore is untrusted. The adversary can view the content of all requests to the Datastore API. And the datastore can be modified by the adversary.

So everything stored in Datastore should be encrypted or hashed.

Revoked User Adversary

User will record all of the requests that their client makes to Datastore and the corresponding responses.

When a user has their access to a shared file revoked, that user may be malicious and use the Datastore API directly.

Data structure

User related structures: UserInfo, UserMeta. UserInfo has the pointer to the UserMeta block stored in the Datastore, which let the different login user endpoint access the latest metadata of the user (file ownership, sharing, asymmetric keys).

File structure (FileHeader). The Owner of the file has the address to the FileHeader which contains the file related information (filename, content links). I user an array of UUIDs to record the content blocks, which improve the append operation efficiency.

Invitation structure (InvitationBlock). These block is used to communicate between the acceptor and the provider using asymmetric encryption. The InvitationBlock contains encrypted Address of FileHeader using the Public Key of the acceptor. And the InvitationBlock contains the provider's signature for integrity.

General structure.

• Address. Contain two symmetric keys (EncKey, MacKey) and a UUID. With this structure, one can access the block in Datastore securely.
• DatastoreValue. Contain two member for storing encrypted data and its MAC. If I want to store a plaintext to Datastore, I serialize it, encrypt it and mac it to build a DatastoreValuestructure. Then I can save this structure to Datastore related to an Address.

User Authentication

When user login, we deterministically find the User structure and check whether the password match the password hash. Then use the password (good source of entropy) to derived MAC key to check the User structure is untampper. The User struct save the login user's password for future keys' derivation (encryption key, mac key).

File Storage and Retrieval

When user save a new file, user create new FileHeader and file related keys (symmetric). User save the mapping of the filename to Address of FileHeader in the table of users's metadata block.

The file owner retrieve the file content by directly access the FileHeader. The acceptor should first access the InvitationBlock to acquire the latest address of the FileHeader.

When appending, accessible user create new content block and add it's UUID to the FileHeader.

Both owners and acceptors use the same keys related to the File.

File Sharing and Revocation

When user (owner or acceptor) want to share the file to another user, the user create a new InvitationBlock which contains the Address of the FileHeader. The provider give the UUID of the InvitationBlock to the acceptor.

When the owner wants to revoke from the acceptor, the owner delete the InvitationBlock and move the FileHeader to a new place (content blocks are also moved). Then the owner updates others InvitationBlock with new FileHeader address.

Cryptography Notes

• When doing the symmetric encryption, we need to provide the initial vector (IV) for the cyphertext generation. But we do not need to record the IV because it will appear in the cypherblock. Each time we want to encrypt, we generate new IV.
• Public Key is for encryption (Verify). Private Key is for decrption (Sign). Combine the asymmetric and symmetric cryptography to implement the secure and efficient communication over insecure channel.
• Encrypt then Mac. Mac then Decrypt. Pay attension to the order. textbook
• Use different symmetric keys for single data encryption and MAC. Prevent copy-paste attacks.
• READ THE DOCUMENT CAREFULLY!