My undergraduate thesis on a capability based security system for a data-centric operating system.
keypar!
+18
-19
+18
-19
2-keypair.typ
+18
-19
2-keypair.typ
···
11
11
capability signatures in section 3.1.
12
12
13
13
14
-
They keys are represented as follows:
14
+
The keys are represented as follows:
15
15
16
16
```rust
17
17
struct Key {
18
-
key: [u8; MAX_KEY_SIZE],
19
-
len: u64,
20
-
scheme: SigningScheme,
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
21
}
22
22
```
23
23
Since the underlying data is just a byte array, the keys themselves are
24
24
scheme-agnostic, enabling support for multiple cryptograhic schemes, as
25
-
described in @twizzler. This also makes backward compatibility trivial when
26
-
adding new signing schemes.The keys are stored inside of objects, allowing for
27
-
persistent or volatile storage depending on object specification, and allows for
28
-
keys themselves to be treated as any other object and have security policy
29
-
applied to them.
25
+
described in the Twizzler security paper @twizzler. The enum also makes backward
26
+
compatibility trivial when adding new signing schemes. The keys are stored inside
27
+
of objects, allowing for persistent or volatile storage depending on object
28
+
specification, and allows for keys themselves to be treated as any other object
29
+
and have security policy applied to them.
30
30
31
31
== Abstraction
32
32
Currently we use the Elliptic Curve Digital Signature Algorithm (ECDSA) @ecdsa
···
35
35
represented as bytes.
36
36
37
37
An existing drawback for backward compatibility is the maximum size
38
-
of the buffer we store the key in. Currently we set the maximum size as 256
39
-
bytes, meaning if a future cryptographic signing scheme was to be created with
38
+
of the buffer we store the key in. Currently the maximum size as 256
39
+
bytes, meaning if a future cryptographic signing scheme was to be added with
40
40
a key size larger than 256 bytes, we would have to drop backwards
41
41
compatibility. While this can be prevented now by setting the maximum size to
42
42
something larger, it ends up being tradeoff between possible cryptographic schemes
···
45
45
== Compartmentalization
46
46
// how they can be used to sign multiple objects (compartmentalization)
47
47
48
-
To create an object in twizzler, you specify the ID of a verifying key
49
-
object so the kernel knows which key to use to verify any
50
-
capabilities permitting access to the object. Since keys are represented as objects
51
-
in twizzler, security policy applies on them as well, creating satisfying
52
-
solutions in regards to key management.
48
+
To create an object in Twizzler, you specify the ID of a verifying key object so
49
+
the kernel knows which key to use to verify any capabilities permitting access
50
+
to the object. Since keys are represented as objects, security policy applies on
51
+
them as well, creating satisfying solutions in regards to key management.
53
52
54
-
Suppose for instance we have Alice on Twizzler, and all users on Twizzler have
55
-
a "user-root" keypair that allows for them to create an arbitrary number of
53
+
Suppose for instance we have Alice on Twizzler, and all users have
54
+
a "user-root" keypair that allows them to create an arbitrary number of
56
55
objects. Also suppose that access to this user-root keypair is protected by
57
-
some login program, where only alice can log in. This means that Alice
56
+
some login program, where only Alice can log in. This means that Alice
58
57
can create new keypair objects from her user-root keypair. Since all
59
58
*her* new keypairs originate from *her* original user-root keypair, only *she* can
60
59
access the keys required to create new signatures allowing permissions into
thesis.pdf
thesis.pdf
This is a binary file and will not be displayed.