My undergraduate thesis on a capability based security system for a data-centric operating system.
aaaaaaa
+168
-58
+35
-50
2-keypair.typ
+35
-50
2-keypair.typ
···
4
4
#mol-chapter("Key Pairs")
5
5
6
6
// what are keypair objects ?
7
-
Key pairs in Twizzler are the representation of the cryptographic signing schemes
8
-
used to create a signed capability, discussed in 3.1.
9
-
We design the keypair objects to be agnostic towards what cryptographic
10
-
schemes are underneath, allowing for the underlying algorithm to be changed
11
-
@twizzler. The keys themselves are stored inside of objects, allowing for
12
-
persistent or volatile storage depending on object specification, and
13
-
allows for keys themselves to be treated as any other object and have security
14
-
policy applied to them. This allows for powerful primitives and rich
15
-
expressiveness for describing secruity policy, while also being flexible enough
16
-
to make basic policy easy.
7
+
Key pairs in Twizzler are the representation of the cryptographic signing
8
+
schemes used to create a signed capability, discussed in 3.1. We design
9
+
the keypair objects to be agnostic towards what cryptographic schemes are
10
+
underneath, allowing for the underlying algorithm to be changed @twizzler. The
11
+
keys themselves are stored inside of objects, allowing for persistent or
12
+
volatile storage depending on object specification, and allows for keys
13
+
themselves to be treated as any other object and have security policy applied
14
+
to them. This allows for powerful primitives and rich expressiveness for
15
+
describing secruity policy, while also being flexible enough to make basic
16
+
policy easy.
17
17
18
-
Suppose for instance we have Alice on Twizzler, and all users on twizzler
19
-
have a "user-root" keypair that allows for them to create an arbitrary number of
20
-
objects. Also suppose that access to this user-root keypair is protected by some
21
-
login program, where only alice can log in. This now means that Alice now
22
-
can create new keypairs, protected by her user-root keypair. Since all her
23
-
new keypairs originate from her original user-root keypair, only she can access
24
-
the keys required to create new signatures of hers. It forms an elegant solution for
25
-
capability creation without the involvement of the kernel.
26
-
27
-
28
-
29
-
30
-
// how are they represented in twizzler ?
31
18
32
19
== Abstraction
33
20
34
21
The `SigningKey` struct is a fixed length byte array with a length field
35
22
and an enum specifying what algorithm that key should be interpreted as.
36
-
Currently we use the Elliptic Curve Digital Signature Algorithm (ECDSA)
37
-
@ecdsa to sign capabilities and verify them, but the simplistic dat
38
-
arepresentation allows for any arbitrary alogrithm to be used as long as
39
-
the key can be represented as bytes.
23
+
Currently we use the Elliptic Curve Digital Signature Algorithm (ECDSA) @ecdsa
24
+
to sign capabilities and verify them, but the simplistic data representation
25
+
allows for any arbitrary alogrithm to be used as long as the key can be
26
+
represented as bytes.
40
27
41
-
Additionally this specification allows
42
-
for backward compatibility, allowing for an outdated signing scheme to be used in
43
-
support of older programs / files. An existing drawback for backward compatibility is the
44
-
maximum size of the buffer we store the key in. Currently we set the maximum size as 256 bytes,
45
-
meaning if a future cryptographic signing scheme was to be found with a private key size
46
-
larger than 256 bytes, we would have to drop backwards compatibility. Sure this
47
-
can be prevented by setting the maximum size to something larger, but that a tradeoff
48
-
between possible cryptographic schemes vs the real on-disk cost of larger buffers.
28
+
Additionally this specification allows for backward compatibility, allowing
29
+
for an outdated signing scheme to be used in support of older programs /
30
+
files. An existing drawback for backward compatibility is the maximum size
31
+
of the buffer we store the key in. Currently we set the maximum size as 256
32
+
bytes, meaning if a future cryptographic signing scheme was to be found with
33
+
a private key size larger than 256 bytes, we would have to drop backwards
34
+
compatibility. Sure this can be prevented by setting the maximum size to
35
+
something larger, but that a tradeoff between possible cryptographic schemes
36
+
vs the real on-disk cost of larger buffers.
49
37
50
38
== Compartmentalization
51
39
// how they can be used to sign multiple objects (compartmentalization)
52
40
53
41
To create an object in twizzler, you specify the id of a verifying key
54
42
object so the kernel knows which key to use to verify any
55
-
capabilities permitting access to the object. You can also specify
56
-
default protections for an object or create a capability with the signing
57
-
key and any desired permissions.
58
-
59
-
The neat thing about this design is that you can use a single keypair in-order to use
60
-
any arbitrary amount of objects. An example could be a colletion of objects holding files for a class, and grouping all of them
61
-
under the same key. In short, having this flexibility allows for a significant debloating
62
-
of the filesystem, comparted to creating a new keypair for every single object.
43
+
capabilities permitting access to the object. Since keys are represented as objects
44
+
in twizzler, security policy applies on them as well, creating satisfying
45
+
solutions in regards to key management.
63
46
64
-
In planned future work , as we talk more about in
65
-
we can investiage the This results in the possibility of finegrained
66
-
access control to semantic groupings of objects.
67
-
// what the fuck am i trying to say
47
+
Suppose for instance we have Alice on Twizzler, and all users on twizzler have
48
+
a "user-root" keypair that allows for them to create an arbitrary number of
49
+
objects. Also suppose that access to this user-root keypair is protected by
50
+
some login program, where only alice can log in. This now means that Alice
51
+
now can create new keypair objects from her user-root keypair. Since all
52
+
her new keypairs originate from her original user-root keypair, only she can
53
+
access the keys required to create new signatures allowing permissions into
54
+
her objects. It forms an elegant solution for capability creation without
55
+
the involvement of the kernel.
68
56
69
-
// all it does is make creation easier, since you only need one pair, it doesnt
70
-
// restrict capabilities or whatever. It's just a benefit since we dont have to worry
71
-
// about managing a keypair for every single object
72
57
73
58
#load-bib(read("refs.bib"))
+111
-5
5-results.typ
+111
-5
5-results.typ
···
1
1
#import "template.typ": *
2
+
3
+
#import "@preview/unify:0.7.1"
2
4
#mol-chapter("Results")
3
5
4
6
// benchmarking
···
13
15
//
14
16
// take measurements without security checks too so you can see the security overhead
15
17
//
16
-
All testing was done in QEMU, with a Ryzen 5 2600 processor.
17
18
19
+
== Validation
18
20
19
-
== Validation
21
+
The first test is a basic scenario as a check to make sure the system is behaving as intended, and
22
+
a more expressive test to demonstrate the flexibility of the model. Eventually I intend to work with
23
+
my advisor and peers to form a proof of correctness for the security model, as well
24
+
as empirical testing to demonstrate its rigidity.
20
25
21
26
=== Basic
22
-
23
-
24
-
=== Expressive
27
+
TBA
28
+
== Expressive
29
+
TBA
25
30
26
31
27
32
== Micro Benchmarks
33
+
Additionally we have microbenchmarks of core security operations in Twizzler. All
34
+
benchmarks were ran with a Ryzen 5 2600, with Twizzler virtualized in QEMU. Unfortunately
35
+
I ran out of time to perform benchmarks on bare metal, but they should be the same, if
36
+
not more, performant.
28
37
29
38
=== Kernel
30
39
40
+
Theres a couple things we benchmark inside the kernel, including core cryptographic
41
+
operations like signature generation and verification, as well as the total time it takes
42
+
to verify a capability.
43
+
#figure(
44
+
table(
45
+
columns: (auto, auto),
46
+
inset: 10pt,
47
+
align: center,
48
+
table.header(
49
+
[Benchmark], [Time]
50
+
),
51
+
[
52
+
Hashing (Sha256)
53
+
],
54
+
[
55
+
267.86 ns $plus.minus 163$ ns
56
+
],
57
+
[
58
+
Hashing (Blake3)
59
+
],
60
+
[
61
+
125.99 ns $plus.minus 117$ ns
62
+
],
63
+
[
64
+
Signature Generation (ECDSA)
65
+
],
66
+
[
67
+
199.90 $\u{00B5}s plus.minus 9.45 \u{00B5}s$
68
+
],
69
+
70
+
[
71
+
Signature Verification (ECDSA)
72
+
],
73
+
[
74
+
342.20 $\u{00B5}s plus.minus 6.28 \u{00B5}s$
75
+
] ,
76
+
[
77
+
Capability Verification (ECDSA, Blake3)
78
+
],
79
+
[
80
+
343.59 $\u{00B5}s plus.minus 5.32 \u{00B5}s$
81
+
]
82
+
),
83
+
caption: [Collection of Kernel Benchmarking Results]
84
+
)
85
+
86
+
We see that signatures are vastly more expensive than hashing, on an order
87
+
of $10^3$, meaning that your choice of hashing algorithm doesnt affection the
88
+
total time taken for the verification of a capability. It's also important to
89
+
note that this cost of verifying a capability for access is done on the first
90
+
pagefault, then the kernel uses caching to store the granted permissions and
91
+
provieds those on subsequent page faults into that object. In the future I hope
92
+
to measure the difference between a cached and uncached verification. Secondly
93
+
we only measure verification inside kernel space; as disscussed in section 3,
94
+
capability creation only takes place in user space.
31
95
32
96
=== UserSpace
97
+
98
+
In userspace we benchmark keypair and capability creation, as these operations are core to
99
+
creating security policy.
100
+
101
+
102
+
#figure(
103
+
table(
104
+
columns: (auto, auto),
105
+
inset: 10pt,
106
+
align: center,
107
+
table.header(
108
+
[Benchmark], [Time]
109
+
),
110
+
[
111
+
Capability Creation
112
+
],
113
+
[
114
+
347.97 $\u{00B5}s plus.minus 5.78 \u{00B5}s$
115
+
],
116
+
[
117
+
Keypair Objects Creation
118
+
],
119
+
[
120
+
651.69$\u{00B5}s plus.minus 187.90 \u{00B5}s$
121
+
],
122
+
[
123
+
Security Context Creation
124
+
],
125
+
[
126
+
282.10$\u{00B5}s plus.minus 119.90 \u{00B5}s$
127
+
],
128
+
),
129
+
caption: [Collection of UserSpace Benchmarking Results]
130
+
)
131
+
132
+
Almost all the time spent in creating a capability is the cryptographic operations used
133
+
to form its signature, which is why its in the same ballpark as signature creation we saw earlier.
134
+
135
+
The high varince in Keypair objects and Security contexts creation happens from the
136
+
unpredictable time it takes for the kernel to create an object on disk. The reason keypair's
137
+
are almost 2x more expensive since it creates two seperate objects, one for the signing key,
138
+
and one for the verifying key.
+20
-1
6-conclusion.typ
+20
-1
6-conclusion.typ
···
2
2
3
3
#mol-chapter("Conclusion")
4
4
5
+
In short we provide a general overview of the critical security
6
+
components for security system in Twizzler, along with
7
+
implementation details and desgin descisions. The evaluation programs show how
8
+
security policy can be expressed and verifies that the kernel is enforcing as
9
+
programmed. Lastly we go over microbenchmarks to show and explain the cost of these operations.
10
+
11
+
5
12
== Future Works
6
13
7
14
In the future I hope to take the primitives created during my thesis, and apply them towards
8
-
the implementation of Decentralized Information Flow Control, as described in
15
+
the implementation of Decentralized Information Flow Control, as described in @flume, into
16
+
the Twizzler security model. Additionally I would love to see how the current security model
17
+
evolves once we start adding distributed computing support to Twizzler, as described in
18
+
the orignal paper @twizzler.
19
+
20
+
21
+
== Acknowledgements
22
+
23
+
I couldn't have done the work for this thesis and for Twizzler if it wasn't for the
24
+
support I've recieved from my advisor Owen Arden and my technical mentor Daniel Bittman! I
25
+
owe both of you so much, not just for the class credit but also for how much I've learned in
26
+
this endeavor. Thanks guys!
27
+
9
28
10
29
11
30
#load-bib(read("refs.bib"))
+2
-2
template.typ
+2
-2
template.typ
thesis.pdf
thesis.pdf
This is a binary file and will not be displayed.