My undergraduate thesis on a capability based security system for a data-centric operating system.
1#import "template.typ": *
2
3
4#mol-chapter("Key Pairs")
5
6// what are keypair objects ?
7Key-Pairs in Twizzler are two objects, one containing a signing key, and the
8other having a verifying key. The signing key is used to form the signature when
9creating a capability, while the verifying key is used by the kernel to validate
10a capability before granting access rights. More detail can be found about
11capability signatures in section 3.1.
12
13
14The keys are represented as follows:
15
16```rust
17struct Key {
18 buf: [u8; MAX_KEY_SIZE], /// Buffer storing the bytes of keys.
19 len: u64, /// The length of key in bytes.
20 scheme: SigningScheme, /// Enum marking what scheme the key is.
21}
22```
23Since the underlying data is just a byte array, the keys themselves are
24scheme-agnostic, enabling support for multiple cryptograhic schemes, as
25described in the Twizzler security paper @twizzler. The enum also makes backward
26compatibility trivial when adding new signing schemes. The keys are stored inside
27of objects, allowing for persistent or volatile storage depending on object
28specification, and allows for keys themselves to be treated as any other object
29and have security policy applied to them.
30
31== Abstraction
32Currently we use the Elliptic Curve Digital Signature Algorithm (ECDSA) @ecdsa
33to sign capabilities and verify them, but the simplistic data representation
34allows for any arbitrary algorithm to be used as long as the key can be
35represented as bytes.
36
37An existing drawback for backward compatibility is the maximum size
38of the buffer we store the key in. Currently the maximum size as 256
39bytes, meaning if a future cryptographic signing scheme was to be added with
40a key size larger than 256 bytes, we would have to drop backwards
41compatibility. While this can be prevented now by setting the maximum size to
42something larger, it ends up being tradeoff between possible cryptographic schemes
43vs the real on-disk cost of larger buffers, something we plan to investigate in future work.
44
45== Compartmentalization
46// how they can be used to sign multiple objects (compartmentalization)
47
48To create an object in Twizzler, you specify the ID of a verifying key object so
49the kernel knows which key to use to verify any capabilities permitting access
50to the object. Since keys are represented as objects, security policy applies on
51them as well, creating satisfying solutions in regards to key management.
52
53Suppose for instance we have Alice on Twizzler, and all users have
54a "user-root" keypair that allows them to create an arbitrary number of
55objects. Also suppose that access to this user-root keypair is protected by
56some login program, where only Alice can log in. This means that Alice
57can create new keypair objects from her user-root keypair. Since all
58*her* new keypairs originate from *her* original user-root keypair, only *she* can
59access the keys required to create new signatures allowing permissions into
60*her* objects. It forms an elegant solution for key management without
61the involvement of the kernel.
62
63// nice, we should talk more about this
64#load-bib(read("../refs.bib"))