1
00:00:00,000 --> 00:00:04,660
I'm an architect and a software engineer.

2
00:00:04,660 --> 00:00:09,460
I've designed and built the Nexus platform and the TAO framework.

3
00:00:09,460 --> 00:00:15,840
And so I'm here today to discuss with you about security-focused operating system design.

4
00:00:15,840 --> 00:00:22,320
A lot of this has kind of become born with the invention of the blockchain, right?

5
00:00:22,320 --> 00:00:35,080
Other methods of securing the operating system I've seen through methods of logical attestation that usually use a trusted platform module in order to create different security properties in the final system in the operating system.

6
00:00:35,080 --> 00:00:41,660
So this presentation I'm going to discuss exactly how some of these architectural components fit together.

7
00:00:42,240 --> 00:00:48,480
This operating system, LLLOS, is something that has begun development.

8
00:00:48,480 --> 00:00:56,040
So we're just in the final stages of architectural and we're now moving forward into the actual development cycles.

9
00:00:56,040 --> 00:00:58,960
So what is LLLOS?

10
00:00:58,960 --> 00:01:01,180
LLL stands for lower-level library.

11
00:01:01,180 --> 00:01:03,800
So this is a polymorphic template library.

12
00:01:03,800 --> 00:01:05,560
It's developed in C++.

13
00:01:05,560 --> 00:01:11,280
And it's the foundation of the TAO framework and all of the other components of Nexus.

14
00:01:11,280 --> 00:01:16,280
So it contains three main components, the LLC, the LLD, and the LLP.

15
00:01:16,420 --> 00:01:20,760
Otherwise known as lower-level cryptography, lower-level database, and lower-level protocol.

16
00:01:20,760 --> 00:01:29,040
So it's designed to be a standalone template database or template library that you can build different applications on.

17
00:01:29,040 --> 00:01:32,180
One of which is going to be this operating system.

18
00:01:32,180 --> 00:01:37,920
So the lower-level database is a constant-time database, order of one.

19
00:01:37,920 --> 00:01:43,260
So as far as our tests have gotten, we've gotten above a billion keys.

20
00:01:43,260 --> 00:01:46,540
And you have maybe about a 20% reduction in performance.

21
00:01:46,540 --> 00:01:48,500
So that's a very important component.

22
00:01:48,500 --> 00:01:55,360
As we start managing ever-growing datasets for blockchains, we need the database to actually not slow down.

23
00:01:55,560 --> 00:02:00,300
So we've been developing this database specifically over the past four years.

24
00:02:00,300 --> 00:02:08,060
And more recently have finally, with the combination of hash maps and bloom filters, primary and secondary bloom filters, and many other range proofs and things like that.

25
00:02:08,060 --> 00:02:13,120
We've been able to get it, like I said, up to a billion keys without actually losing any performance.

26
00:02:13,120 --> 00:02:19,620
The average read performance, random reads, is 180,000 records per second with no memory caching.

27
00:02:19,720 --> 00:02:25,240
The average write performance is 120,000 records per second with no buffering.

28
00:02:25,240 --> 00:02:26,880
That's just straight to the disk.

29
00:02:26,880 --> 00:02:34,160
And then the average number of keys that can be checked per second is about 630,000 without actually having to read the data.

30
00:02:34,160 --> 00:02:36,280
So this is just checking in the keychain.

31
00:02:36,620 --> 00:02:40,380
So the lower-level database is extremely fast, extremely efficient.

32
00:02:40,380 --> 00:02:47,120
And the beautiful thing is, as the dataset gets larger and larger and larger, you still retain that performance.

33
00:02:47,120 --> 00:02:53,000
So when you get close to a full dataset, it'll go down to about 150,000 random reads per second.

34
00:02:53,000 --> 00:02:58,460
And then the sequential reads end up being about 1.2 million records per second for sequential reads.

35
00:02:58,460 --> 00:03:03,280
So it's a very, very fast, low-level database that's designed for blanching applications.

36
00:03:03,280 --> 00:03:09,140
And it's part of the foundation of this operating system for managing different file clusters and things such as that.

37
00:03:09,140 --> 00:03:14,940
So the lower-level operating system is being designed for authentication up and down the OSI stack.

38
00:03:14,940 --> 00:03:19,380
For those that don't know what the OSI stands for, it stands for Open Systems Interconnection.

39
00:03:19,380 --> 00:03:23,760
And it is somewhat of a template stack that most of the Internet is built on.

40
00:03:24,120 --> 00:03:27,840
And it contains seven layers, which we'll get to on the next slide.

41
00:03:28,240 --> 00:03:32,580
The LLOS is being implemented for cube satellites and IoT devices first.

42
00:03:32,580 --> 00:03:40,580
So the consumer version of the operating system will be coming quite a bit later because there's a lot of extra user virtualization that needs to be done.

43
00:03:40,580 --> 00:03:45,120
But the core foundation of it is going to be running on IoT and cube satellites.

44
00:03:45,300 --> 00:03:48,660
And it virtualizes the user space through distributed computing.

45
00:03:50,480 --> 00:03:52,260
So what is Nexus?

46
00:03:52,320 --> 00:03:56,020
So Nexus is a seven-layer software stack as well as the OSI.

47
00:03:56,020 --> 00:04:01,200
And it's designed to interweave with the OSI stack, as you can see.

48
00:04:01,200 --> 00:04:08,560
You have the base layers, the physical layer, and then the data link, and then the network, transport, session, presentation, and application layer.

49
00:04:08,560 --> 00:04:10,020
And this is the OSI.

50
00:04:10,120 --> 00:04:21,200
So Nexus has seven layers as well, which is the network layer for the base layer, the ledger layer, then the register layer, the operation layer, the API layer, the logical layer, and the interface.

51
00:04:21,600 --> 00:04:30,140
So this Nexus software stack is designed to, as I said, interweave within the OSI and improve the security properties.

52
00:04:30,140 --> 00:04:34,660
As many of you know, the Internet was not developed with many security properties in mind.

53
00:04:34,660 --> 00:04:49,440
And operating systems, their design is a little bit archaic because we have new technology that can actually prevent a lot of the exploits that are available right now, such as ROP exploits and file system tampering and things such as that.

54
00:04:49,660 --> 00:04:53,080
So Nexus is a part of this LLOS.

55
00:04:53,080 --> 00:04:55,440
We'll be running in the kernel space, not the user space.

56
00:04:55,440 --> 00:05:13,780
And it's going to be using registers to authenticate and verify different pieces of this kernel, which is going to protect the kernel from having remote injection attempts, which I usually use the analogy most kernels are kind of like a big gooey lot.

57
00:05:13,780 --> 00:05:16,880
And you can inject anything into it, and the computer is just going to execute it.

58
00:05:16,880 --> 00:05:24,560
That's how ROP exploits work, is you just override a part of the executable memory, and then you're able to inject a virus right in through their open port.

59
00:05:24,560 --> 00:05:28,420
So this fortifies the kernel.

60
00:05:28,420 --> 00:05:31,620
What it does is it allows the kernel to know itself, right?

61
00:05:31,620 --> 00:05:41,660
Because when something doesn't know itself, it's very difficult for it to determine if there's an attack, because an attack is generally some sort of change in the normal conditions, normal operating conditions.

62
00:05:41,660 --> 00:05:57,200
So when we add Nexus into this kernel space, what we're able to do is we're able to start to discern, as a software operating system, what it is and what it isn't, so that you can detect new viruses coming into it.

63
00:05:57,200 --> 00:06:04,940
It's kind of like an immune system for your body, where the T cells are able to identify a virus because it knows itself and it knows something that's foreign.

64
00:06:04,940 --> 00:06:12,380
The same type of thing with the operating system is the operating system is going to know its base-level functionality, and it will be able to detect anything foreign that comes through.

65
00:06:12,680 --> 00:06:17,300
So a brief explanation of two of the layers of the Nexus software stack.

66
00:06:17,300 --> 00:06:25,180
The ledger layer, which is the second layer, it essentially manages ownership of the registers, and it's responsible for chaining data into immutable objects.

67
00:06:25,180 --> 00:06:29,200
It's verified through locking mechanisms that are validated through global consensus.

68
00:06:29,560 --> 00:06:34,500
Those are proof-of-stake, proof-of-work, and practical by default-tolerant algorithms.

69
00:06:34,500 --> 00:06:38,020
And it proves ownership and permissions of registers on the layer above.

70
00:06:38,580 --> 00:06:48,920
Now, the register layer, which is what we're going to be utilizing mostly in the development of this operating system, registers are little-state objects that hold data owned by the user that published it.

71
00:06:48,920 --> 00:06:53,160
And they can be transferred, written, or be used as proofs on the operations layer above.

72
00:06:53,400 --> 00:06:58,640
Now, object registers are a type-safe programmable object, allowing the creation of custom data types.

73
00:06:58,640 --> 00:07:02,480
And registers can point to one another, forming relational database models.

74
00:07:02,480 --> 00:07:11,820
So, when we're getting to the security-focused operating system design, LLOS has three main architectural components that will provide security to the kernel.

75
00:07:11,900 --> 00:07:15,860
The first one is runtime, memory, and binary verification.

76
00:07:15,900 --> 00:07:18,880
The second one is file integrity and Merkle trees.

77
00:07:18,880 --> 00:07:21,580
And then the third one is software-defined routers.

78
00:07:21,580 --> 00:07:26,100
And I'll get to each one of these points as we extrapolate it out further.

79
00:07:26,500 --> 00:07:30,020
So, runtime, memory, and binary verification.

80
00:07:30,020 --> 00:07:32,140
This is to protect against buffer overflows.

81
00:07:32,140 --> 00:07:40,120
Right now, the main ways that we can protect against buffer overflow attacks on the kernel space is to do randomized address creation.

82
00:07:40,120 --> 00:07:46,060
Or you do some form of allocation of only a certain aspect of the memory is actually executable.

83
00:07:46,060 --> 00:07:51,680
So that if you have an ROP exploit that does buffer overflow, it makes it very difficult.

84
00:07:51,680 --> 00:07:52,420
Yes.

85
00:08:00,910 --> 00:08:02,810
You're not seeing the changing slide?

86
00:08:04,290 --> 00:08:05,630
Is this better?

87
00:08:05,630 --> 00:08:07,850
Or are you still stuck on the first one?

88
00:08:12,080 --> 00:08:13,600
You can see it now?

89
00:08:14,720 --> 00:08:15,680
Okay.

90
00:08:15,940 --> 00:08:22,020
So, with the runtime, memory, and the binary verification, we're essentially able to start to isolate.

91
00:08:22,020 --> 00:08:28,560
We take some of the properties of protecting against buffer overflows, such as having a certain portion of the memory being executable.

92
00:08:28,560 --> 00:08:36,240
But what we do, especially if we're doing compiling environments, is you have to authenticate any executable code.

93
00:08:36,240 --> 00:08:51,480
So if there's any sort of memory that's loaded into the memory when I first execute the binary, that, when it is first loaded, is verified against a register entry as a checksum, which will ensure that you know the exact instruction set that is being executed by the CPU.

94
00:08:51,480 --> 00:08:58,480
And before anything is passed into the CPU, you are able to determine if it was tampered with.

95
00:08:58,480 --> 00:09:04,660
So we authenticate every aspect of the runtime environment, essentially requiring user action to change the kernel state.

96
00:09:04,660 --> 00:09:09,860
We use memory randomization, but more importantly, only small sections of the page memory will be executable.

97
00:09:09,860 --> 00:09:26,120
And as I was saying earlier, before we pass anything into the actual CPU, we want to run it through an authentication system, which is essentially verifying the checksum either on a blockchain register or a digital signature that is verified off of the crypto object register.

98
00:09:26,120 --> 00:09:30,260
And I will get to that in a little bit, how the architecture of Nexus works.

99
00:09:30,480 --> 00:09:34,340
But there's a special register that's created when you create a new signature chain.

100
00:09:34,340 --> 00:09:39,520
It contains a number of hashes that correlate to specific public keys.

101
00:09:39,640 --> 00:09:49,580
So this allows you to do offline verification of identity and verifying specific pieces of data without having to actually touch the blockchain or create a new blockchain entry.

102
00:09:49,640 --> 00:09:54,500
When you touch the blockchain, it would be generally mutating the state of a register.

103
00:09:54,500 --> 00:09:58,320
So if you're modifying a file, you would have to actually modify the blockchain state.

104
00:09:58,320 --> 00:10:13,380
But if you're just doing basic runtime environments, you have a user action required when you compile it that will sign that specific bytecode into a checksum to ensure that if any time during the runtime there is an exploit that happens to overwrite some of the executable memory,

105
00:10:13,380 --> 00:10:24,600
before that is actually executed from a function call, it will have to be verified through the blockchain register, which will protect any type of remote injection attack.

106
00:10:24,600 --> 00:10:30,020
So any part that is executed will require a user action to change executable memory.

107
00:10:30,020 --> 00:10:46,840
Like I was saying, a user action could be anything from updating the state of a register on the blockchain itself or using one of the crypto object register keys to sign any piece of data, which is another form of authentication that does not necessarily require the updating of a register state.

108
00:10:46,840 --> 00:11:03,980
So more persistent level data is going to be updated in registers and more temporary data such as a recently compiled binary will be just signed as a type of notarization, which will protect that specifically from being mutated if there's anything bad that happens during runtime.

109
00:11:03,980 --> 00:11:09,740
Runtime instructions must be authenticated with the register allocated on Nexus in order to be executed.

110
00:11:09,740 --> 00:11:18,660
So if I download a new application, the application developer will have a blockchain register associated with the binary that they created.

111
00:11:18,720 --> 00:11:22,600
So it's the same type of way of hashing your binary before you execute them.

112
00:11:22,600 --> 00:11:33,540
The kernel itself is going to be doing that on every level and verifying that off of a blockchain entry so that you won't have to necessarily manually go and verify the binary has not been tampered with.

113
00:11:33,540 --> 00:11:45,500
You're going to be able to do that at runtime and it's going to be fully automated so that any time that you're executing any bytecode on this operating system, it's going to be fully authenticated to ensure that nothing was tampered with during runtime.

114
00:11:45,500 --> 00:11:50,880
And these checks are going to be happening every so often to ensure that nothing has continued to be tampered with.

115
00:11:50,880 --> 00:11:54,620
Anything that goes to the CPU has to be verified before it runs.

116
00:11:54,620 --> 00:12:02,780
And that's a really important distinction that's going to protect this operating system architecture from exploits that are currently available on current computers.

117
00:12:02,780 --> 00:12:24,840
Because as I'm sure you guys know, user account control on Windows, to bypass it, you simply just inject your malware directly into explorer.exe and it executes that with elevated privileges because the operating system doesn't know what it was before the virus came in and it just executes and sends every instruction that's executable to the CPU without having any levels of discernment.

118
00:12:24,840 --> 00:12:29,700
And that's one thing that has created massive security flaws in so many different operating system designs.

119
00:12:29,700 --> 00:12:35,380
But this type of architecture has not been available until the creation of a blockchain.

120
00:12:35,580 --> 00:12:50,460
The other aspects or trusted assistation, which I've seen, which is another operating system design that I've studied, use the trusted platform module to create this type of this trust, I guess you can say, and authentication of different pieces of the data.

121
00:12:50,780 --> 00:12:54,760
But in this case, since we have a blockchain, we don't need to rely on all of those.

122
00:12:54,760 --> 00:12:59,480
And trusted platform module version 2.0 has been known to have backdoors to the NSA.

123
00:12:59,480 --> 00:13:02,180
So that's definitely not something that we want to utilize.

124
00:13:02,220 --> 00:13:09,880
So newly downloaded binaries will be authenticated from the developer's signature chain, requiring authentication before instructions are sent to the CPU.

125
00:13:09,880 --> 00:13:12,120
And that's another really important distinction.

126
00:13:12,120 --> 00:13:15,660
Because that means that nobody will be able to actually modify the binary.

127
00:13:15,660 --> 00:13:21,340
And before anything is ever executed, it's verified against the register that the developer of the software created.

128
00:13:21,340 --> 00:13:36,020
If you're compiling yourself, then you just do a simple digital signature on the end of the compilation that then locks and specifically hashes that into a temporary object that can then be used to determine if any of those instructions change during runtime,

129
00:13:36,020 --> 00:13:44,640
which would be a quick way to detect if there was a buffer overflow or ROP exploit that was used to try to inject a virus into the executable memory.

130
00:13:46,020 --> 00:13:49,400
So file integrity Merkle trees is the second aspect.

131
00:13:49,400 --> 00:13:53,540
So imagine the file system being authenticated using Merkle trees.

132
00:13:53,540 --> 00:14:01,200
But in a sense, you're going to have every block in the file actually contain a hash or be a leaf of that hash in the Merkle trees.

133
00:14:01,200 --> 00:14:07,040
So that you can independently verify the integrity of subsets of the file through having the Merkle path.

134
00:14:07,180 --> 00:14:18,160
And now when you create a new file in your file system, something that's outside of the scope of the kernel in the user space, that's going to require a user action, which is going to generate and compute this Merkle root.

135
00:14:18,160 --> 00:14:26,220
And this Merkle root will end up being a data member inside a special object register that is a pointer to the actual data itself.

136
00:14:26,220 --> 00:14:36,820
So the storage location of the data can be utilizing distributed file systems or your local file system or anything else like that with very high levels of security.

137
00:14:36,820 --> 00:14:45,580
Because we don't need to worry about file system tampering because it always requires this register from the blockchain to actually be verified.

138
00:14:45,640 --> 00:14:51,240
So this allows independent checking of file integrity on a per block level using Merkle paths.

139
00:14:51,240 --> 00:15:03,200
And one reason that we use a Merkle tree and Merkle paths, instead of hashing the entire file, we can only hash small subsets so that if you update an aspect of the file, you don't have to recompute every single hash for every single block.

140
00:15:03,200 --> 00:15:12,240
If you only modify one block, you only need to recalculate the Merkle path and the Merkle root rather than having to calculate every single leaf hash once again.

141
00:15:12,640 --> 00:15:18,080
So what this creates is an immutability quality to the file system and it prevents file system tampering.

142
00:15:18,080 --> 00:15:28,640
So viruses and malware won't be able to inject themselves into your file system because before you open any of the files, it'll check the integrity and you'll be able to detect very quickly if anything is tampered with.

143
00:15:28,640 --> 00:15:37,020
So the kernel itself will be doing this integrity checking and it will require specific user action in order to update on the blockchain.

144
00:15:37,020 --> 00:15:55,900
So this gives you a type of multi-layered security properties because in order to actually attack your physical computer now, you're going to actually have to attack the cryptography existing on the public network which increases the difficulty of the attack and reduces the attack surface down on the operating system level.

145
00:15:56,700 --> 00:16:01,780
So the next one is software-defined routers.

146
00:16:01,780 --> 00:16:08,220
So this is a really important component because Nexus in itself is eventually becoming a new internet protocol.

147
00:16:08,220 --> 00:16:12,820
As you see, we are a software stack similar to the OSI.

148
00:16:12,880 --> 00:16:28,360
And on our network layer, our physical layer, we're developing mesh network technology and satellite technology using ISM frequencies, which are publicly available frequencies, about 5.8 gigahertz band, in order to turn every single device into a node on the network.

149
00:16:28,360 --> 00:16:30,660
And this is where the software-defined routers comes in.

150
00:16:30,660 --> 00:16:35,440
As you guys know, dedicated router hardware is an old technology and it's proving to be ineffective.

151
00:16:35,580 --> 00:16:37,880
IPv6 is a very good example of it.

152
00:16:37,880 --> 00:16:44,240
We've been 20 years since that was actually developed and there's still not IPv6 routes across the internet.

153
00:16:44,280 --> 00:16:48,180
We also have other issues with BGP, which stands for Border Gate Protocol.

154
00:16:48,180 --> 00:16:53,980
Those routing tables can be manipulated and managing a large dynamic state will require a lot of inter-router communication.

155
00:16:53,980 --> 00:17:03,460
So when we're talking about a dynamic mesh network and a dynamic low-Earth orbit satellite constellation, conventional routing systems such as BGP just will not work.

156
00:17:03,780 --> 00:17:15,920
So this operating system in itself, inside the kernel space, will actually be running a software-defined router so that we can actually update it much quicker than you would be able to access the physical hardware.

157
00:17:15,920 --> 00:17:28,520
And what's interesting about it is we'll be able to actually create a stateless routing system that doesn't require a dynamic state to constantly update it and there will be no routing tables that can be manipulated.

158
00:17:28,520 --> 00:17:44,240
And then any time there's a type of mapping required, such as an ARP packet or any type of LISP mapping, which LISP stands for Locator Identifier Separation Protocol, which essentially is decoupling the identifier on the network layer from the actual routing locator.

159
00:17:44,240 --> 00:17:50,940
So in a conventional IP system, your IP address is both your locator, your physical location.

160
00:17:50,940 --> 00:18:04,040
Think of an IP address as a type of machine-readable address to a geographic location, so that when it hits the router and it hops, it knows, okay, I need to go in this specific direction so I'm going to take this route.

161
00:18:04,280 --> 00:18:08,820
And so we need authentication up and down the OSI stack.

162
00:18:08,820 --> 00:18:14,480
In a dynamic routing system, it can be stateless, increasing overall security and reducing the ability to spoof routing locators.

163
00:18:14,480 --> 00:18:25,700
So in LISP terminology, a routing locator is the actual physical location, and then the EID, stands for Endpoint Identifier, is your actual device-level identifier.

164
00:18:25,700 --> 00:18:27,600
So you will always be reachable.

165
00:18:27,600 --> 00:18:31,280
Think of it kind of like a phone number that doesn't change.

166
00:18:31,280 --> 00:18:34,580
When you roam between different cell phone networks, your phone number never changes.

167
00:18:34,740 --> 00:18:36,120
It's only your locator that changes.

168
00:18:36,120 --> 00:18:38,840
So your identifier, aka your phone number, won't ever change.

169
00:18:38,840 --> 00:18:51,860
So each device, including IoT and satellites, will have their own embedded system that uses the Locator Identifier Separation Protocol, which also allows us to connect with the old internet protocols as well.

170
00:18:51,860 --> 00:19:04,580
If you happen to have a gateway on that specific node to the old internet protocol, then that can add as another RLOC in the RLOC set, as well as you can have your software-defined routing system.

171
00:19:04,580 --> 00:19:15,680
So you'll be able to connect and connect with multiple networks at the same time, which is going to be very important as we're starting to expand out into a full, fully-blown new internet architecture.

172
00:19:16,700 --> 00:19:20,940
So a lot of this comes down with a stateless routing system.

173
00:19:20,940 --> 00:19:27,360
So in order to be effective as a new internet protocol, Nexus needs to handle dynamic routing systems for mesh networks and cube satellites.

174
00:19:27,360 --> 00:19:35,760
As I was touching on that, managing the state, especially when we have limited bandwidth from satellites and mesh, is not a viable solution.

175
00:19:35,760 --> 00:19:38,280
So BGP is not something that will work.

176
00:19:38,280 --> 00:20:09,240
So Nexus OS or LLOS contains, in the software-defined routing, a stateless routing system where all you will need to know is about the number of nodes that you are around, your nearest nodes, your nearest neighbors, because it can use a GPS-type routing system where you can actually use the natural positioning of things without needing a machine-readable address like an IP address to point and shoot and actually be able to get a fully effective route without each of the nodes having to know anything about each other.

177
00:20:09,240 --> 00:20:15,820
So this improves the overall network security because we're not relying on a constantly updating dynamic routing table.

178
00:20:15,820 --> 00:20:24,340
And if we wanted to add authentication into that routing table, if we were using, let's say, BGP, it's just going to increase the amount of computing cycles that we're going to need to utilize.

179
00:20:24,340 --> 00:20:37,220
And when we're dealing with cube satellites, computing cycles are extremely important because, if any of you are aware, in low-Earth orbit, you're still within the atmosphere, but you have a lot of radiation still.

180
00:20:37,220 --> 00:20:50,720
And so what happens is you get a high concentration of beta particles, which are essentially just stray electrons, that end up creating a high concentration in the gate of the transistor, which will flip the bit from a zero to a one because, generally,

181
00:20:50,720 --> 00:20:52,200
they're n-channel transistors.

182
00:20:52,200 --> 00:20:59,300
So when the bits flip, then you could ruin an entire data set if you don't have integrity checking on that.

183
00:20:59,300 --> 00:21:11,400
So you have to have multiple CPUs and multiple sticks of memory and a lot of checksumming on all of the internal state changes on the satellite in order to ensure that no radiation has come and tampered with that specific file.

184
00:21:11,400 --> 00:21:13,740
So when we're talking about...

185
00:21:23,690 --> 00:21:41,010
router, so that out-of-box, every device that runs this LLLOS will be able to connect to the routing system but also provide value to the routing system because the routing system will not work if there's not gamification in the underlying routing architecture.

186
00:21:41,010 --> 00:21:46,990
In other words, the internet right now only works because ISPs forward traffic for one another.

187
00:21:46,990 --> 00:21:49,430
And it's kind of an unwritten law.

188
00:21:49,430 --> 00:21:51,550
I'll forward for you if you forward for me.

189
00:21:51,550 --> 00:21:53,970
But that's generally only unicast traffic.

190
00:21:54,230 --> 00:21:59,610
Traffic does not generally get forwarded by ISPs because there's no incentive for them to have that.

191
00:21:59,610 --> 00:22:03,010
So the entire internet game theory is slightly...

192
00:22:03,890 --> 00:22:18,730
is not properly thought out because the internet, kind of like Bitcoin, was an experiment that grew very quickly and became something predominant in the world and they constantly are spending time trying to catch up and resolve the problem that just became from the success,

193
00:22:18,730 --> 00:22:20,010
the initial success.

194
00:22:20,010 --> 00:22:40,490
So this routing system needs to have a type of reputation system built into the protocol so that nodes that route for one another end up becoming higher or having a higher reputation and nodes that do not route for one another end up getting a lower reputation which gives them a lower probability of their packets getting forwarded through the routing system.

195
00:22:40,490 --> 00:22:46,810
And that's a really important component because that will discern the difference between an honest node and a dishonest node.

196
00:22:46,810 --> 00:23:12,630
If somebody comes in just being a leech into the system, they're eventually going to leech themselves into isolation because if they refuse to forward packets for their neighbors, their reputation is going to slowly be reduced to the point where their neighbors will stop forwarding packets for them so they will be disconnected from the mesh network with a lower reputation and unable to route essentially degrading them into just a single device network rather than being able to join the entire network.

197
00:23:12,630 --> 00:23:17,190
So this reputation is a really important component inside the stateless routing system.

198
00:23:17,190 --> 00:23:29,110
And this is why the locator identifier separation protocol is really important because whether or not I'm routing on the regular IP internet protocol or I'm routing on the Nexus protocol, it's going to be...

199
00:23:29,110 --> 00:23:41,650
it's still going to need to have this reputation built into it so that nodes know more about who one another is and they'll all need to have this identifier which is cryptographically enforced.

200
00:23:41,750 --> 00:23:52,450
So as I was stating earlier with this crypto object register which contains nine 256-bit hashes of public keys, there's one specific key called the Lisp key.

201
00:23:52,450 --> 00:24:05,710
So when I create a new RLOC mapping into the mapping system, I'm essentially going to be registering this RLOC which could be an IP address or it could be an NP address or a Nexus protocol address for the stateless routing system.

202
00:24:07,110 --> 00:24:10,750
So it needs to be able...

203
00:24:10,750 --> 00:24:24,290
so in order to register this, I need to make a digital signature and sign this RLOC in with my EID and this mapping needs to be stored in state in the network so that they can know specifically where to send packets to me.

204
00:24:24,290 --> 00:24:29,850
So the locator identifier separation protocol is a really important component to the stateless routing system.

205
00:24:29,850 --> 00:24:36,810
And what it does is it opens us up to create network-level identifiers along with cryptographic identifiers.

206
00:24:36,910 --> 00:24:45,070
And this routing system also contains some elements of the OSI such as ARP, but rather authenticating each device with their own embedded subchain.

207
00:24:45,350 --> 00:24:53,170
So ARP caches will not be able to be corrupted or poisoned in this sense because it will be authenticated.

208
00:24:53,170 --> 00:24:59,070
Like I said, everything up and down the OSI stack needs to be authenticated to provide the security qualities that are required.

209
00:25:01,150 --> 00:25:04,070
So authenticate, authenticate, authenticate.

210
00:25:04,070 --> 00:25:12,490
As I was saying, every aspect of the stack and the operating system needs to authenticate a user's action through an immutable source of truth which is Nexus.

211
00:25:12,530 --> 00:25:25,470
And any changes to the state of the virtualized user space must be accompanied by a digital signature linked to the crypto-object register of the SIG chain or an op-write operation to the register that owns that specific part of the user space.

212
00:25:25,470 --> 00:25:42,450
So this means if I update and save a file this file actually needs to have the blockchain entry updated as well so that you can constantly have a history of changes and you'll also have a checksum, both ciphertext and plaintext in order to ensure that the file is not tampered in any way.

213
00:25:42,450 --> 00:25:53,690
Because when you allow the file system to have injection happen and executable memory to be run then you essentially create a lot of export opportunities for different hackers.

214
00:25:53,810 --> 00:25:56,690
So everything needs to be authenticated.

215
00:25:56,690 --> 00:26:02,950
And now that we have this technology with Nexus and blockchain we can provide these types of authentications.

216
00:26:03,150 --> 00:26:09,190
Beforehand, there always was a need for some centralized counterpart and that's how the Internet's architecture is designed right now.

217
00:26:09,190 --> 00:26:11,570
It only operates because there's trust.

218
00:26:11,870 --> 00:26:21,910
And that model works to a certain degree but it doesn't scale out very far and it also has corruption issues as we've seen with ICANN and Verisign.

219
00:26:21,970 --> 00:26:28,250
ICANN got a really large donation from Verisign and now Verisign can increase the cost of .com domains ad infinitum.

220
00:26:28,250 --> 00:26:33,870
So those types of issues won't really exist on Nexus because everything's going to be authenticated.

221
00:26:33,870 --> 00:26:43,650
You're not going to be able to just masquerade and you're not going to be able to pollute a centralized authority because Nexus becomes that incontrovertible port of truth.

222
00:26:43,690 --> 00:26:50,270
Now, going to the crypto object register again there's another specific hash in there which is for a certificate.

223
00:26:50,490 --> 00:27:05,110
So this is another really important distinction because we can actually, in the Diffie-Hellman key exchange we can actually hash that certificate that they give us and do a blockchain lookup to their blockchain identifier which we call a Genesis ID.

224
00:27:05,230 --> 00:27:14,370
And you can therefore verify with incontrovertible truth that that certificate was generated by the other end user.

225
00:27:14,370 --> 00:27:21,350
So you don't have man in the middle attacks and you don't need to have a public key database which is essentially what a certificate authority is.

226
00:27:21,350 --> 00:27:33,450
So executable instructions must be verified to a blockchain register or digitally signed binary compiled before passing to the CPU to protect against buffer overflow exploits or malware injection into the local files.

227
00:27:33,450 --> 00:27:40,130
So as I was stating earlier, executable memory is going to be treated very, very carefully on the kernel level.

228
00:27:40,130 --> 00:27:47,530
And it will be very, very difficult for you to inject any instructions that were not created on a user's action.

229
00:27:47,530 --> 00:27:56,430
So you will still have security properties or security issues and exploits with social engineering attacks and all of those things.

230
00:27:56,430 --> 00:28:04,810
But what we're doing here is we're essentially reducing the ability for developers to make mistakes that open up significant security holes.

231
00:28:04,810 --> 00:28:09,310
And the operating system protects against that on many different layers through this authentication.

232
00:28:11,270 --> 00:28:24,990
So device level identification is another really important distinction and this ties in with the IoT devices because we need an unforgeable device level authentication that allows easy identification of the device, especially for IoT.

233
00:28:25,210 --> 00:28:39,670
So what we're doing is we're taking a device level identification from deterministic hardware inputs such as IMEI or anything that you can utilize to generate a cryptographic identity which is called the signature chain.

234
00:28:39,670 --> 00:28:42,390
And that's essentially how we manage accounts on Nexus.

235
00:28:42,390 --> 00:28:45,210
A signature chain is kind of like a personal blockchain.

236
00:28:45,210 --> 00:28:50,590
We give it as a mini blockchain that is a local state or a local scope to that specific user.

237
00:28:51,190 --> 00:29:03,810
So when we tie this in with the locator identifier separation protocol, you get this unique identifier as a cryptographic identifier that you can use as a lookup into the global state and the blockchain, essentially.

238
00:29:03,810 --> 00:29:14,170
Or you can use it as a network level identifier that will allow you to do a lookup on the specific person that you are communicating with and decide whether or not you want to accept anything from them.

239
00:29:14,170 --> 00:29:18,130
And this also allows you to authenticate and verify files that are sent to you.

240
00:29:18,150 --> 00:29:26,770
So this gives each device a network identity that exists in the kernel space and is therefore immutable and tied deterministically to the device level hardware identifiers.

241
00:29:27,030 --> 00:29:30,370
So this is really important for...

242
00:29:30,370 --> 00:29:33,650
an example would be a smart lock IoT device.

243
00:29:34,010 --> 00:29:44,870
So this device itself would be running LLOS and it would have a device level signature chain so it has a cryptographic identity on Nexus that can be verified by any individual.

244
00:29:45,110 --> 00:29:53,590
And when you first start the device it's going to require some sort of binding where you're going to bind the device to another identifier.

245
00:29:53,710 --> 00:29:56,890
This identifier is the actual user level signature chain.

246
00:29:56,890 --> 00:30:00,370
The device level signature chain is a device level signature chain.

247
00:30:00,370 --> 00:30:06,810
It doesn't necessarily have all of the full range of operations available as a user signature chain.

248
00:30:06,810 --> 00:30:11,070
And obviously you can't apply a device signature chain to own a device signature chain.

249
00:30:11,070 --> 00:30:15,010
So this user signature chain becomes therefore the control of the device.

250
00:30:15,010 --> 00:30:20,170
Now, the device level signature chain is just for authenticating things specific to that device.

251
00:30:20,170 --> 00:30:33,370
The user level signature chain will exist outside of that device which essentially reduces the capacity for you to be able to hack IoT devices because the device itself will have nothing of value to hack.

252
00:30:33,710 --> 00:30:38,790
There's nothing stored on that device that will be of use to hack.

253
00:30:38,790 --> 00:30:44,750
Because that device level signature chain is going to obey this public signature chain, this user level signature chain.

254
00:30:44,750 --> 00:30:48,030
And it requires that user signature chain in order to have action.

255
00:30:48,030 --> 00:31:00,850
So the attack surface gets greatly reduced from the actual hardware in the device itself and it becomes more of a cryptographic attack on the actual blockchain in order to overtake some of these devices and access them.

256
00:31:00,910 --> 00:31:05,990
So this gives each device a network identity, as I was saying.

257
00:31:05,990 --> 00:31:13,090
And with it being deterministic to the device level hardware that means we'll have unique identifiers for each one of these devices.

258
00:31:13,090 --> 00:31:24,130
Now, each one of these devices will then also have their own unique IP address or crypto EID which will be the identifier so that we'll start to be able to identify each device individually.

259
00:31:24,130 --> 00:31:41,970
So in the example of SmartLock you get the device you set up the device by creating the owner the owner of the device would be the user level signature chain, public signature chain which can be done via a register that's created on the device.

260
00:31:42,070 --> 00:32:04,190
Now, if I have another specific user somebody that is coming to my house let's say at 5 o'clock PM I can set on the device itself or the user level signature chain I create a type of contract that says this device allows this specific identifier to open my door one time at this specific time stamp in the future.

261
00:32:04,190 --> 00:32:28,370
So that that user having another user level signature chain will go to the actual lock and through near field communication will send a digital signature signed from one of the hashed public keys in their crypto object register which is tied to that identifier that cryptographic identifier so the device can authenticate this person is this person cryptographically and then the door can open.

262
00:32:28,370 --> 00:32:54,610
So you create this very interesting type of usage of IoT devices and also a consistent standardization between different devices as I'm sure all of you are aware IoT devices have no standards they have very weak security there's not, there's a lot of explosion in the development of them but not as much understanding of the security properties kind of like the internet was or still is.

263
00:32:54,790 --> 00:33:05,690
So this operating system is also a means to standardize the communication protocols between all these devices and improve the overall IoT security.

264
00:33:06,170 --> 00:33:09,450
So this ties into device synchronization.

265
00:33:09,490 --> 00:33:13,690
Most IoT devices cannot talk to each other due to incompatible hardware and software.

266
00:33:13,890 --> 00:33:23,490
So LLOS is essentially a framework for developers to easily synchronize IoT devices, allocate control of them to a master SIG chain that's authenticated through Nexus.

267
00:33:23,490 --> 00:33:26,490
I gave you guys a quick example of how that all works.

268
00:33:26,790 --> 00:33:33,970
And it also there's one aspect of the API layer that allows you to create peer-to-peer communication.

269
00:33:33,970 --> 00:33:41,090
There's also powerline mesh connectivity, there's local mesh connectivity, and all these things that can integrate together and synchronize the devices.

270
00:33:41,370 --> 00:33:55,070
I sometimes, if I need to send a file from one computer to another computer, the operating system there's some with Apple, with AirDrop and stuff, but there's not very many, very easy to use device synchronization protocols.

271
00:33:55,070 --> 00:33:57,250
You have to download something else, you have to install it.

272
00:33:57,250 --> 00:34:03,690
I mean, even utilizing Linux it's very difficult for a non-developer to utilize it, even if you're using Mint or Ubuntu.

273
00:34:03,690 --> 00:34:07,610
They can kind of get around it, but there's a massive user issue.

274
00:34:07,610 --> 00:34:10,250
And part of that is also just the synchronization problem.

275
00:34:10,250 --> 00:34:19,030
So the Nexus operating system, or LLOS, kind of extends the user space out of the local hardware.

276
00:34:19,170 --> 00:34:19,690
Right ?

277
00:34:19,910 --> 00:34:25,850
It creates a virtualized user space, which I believe is the next slide.

278
00:34:26,130 --> 00:34:36,210
It is not bound to the physical hardware, so it changes the idea of how we see a kernel, rather than actually being something that is managing just that local device.

279
00:34:36,210 --> 00:34:42,550
It kind of exists to manage the local device, but also the cache of the specific virtualized user space is logged in.

280
00:34:42,550 --> 00:34:52,270
So if I go to, let's say, my desktop, and I log in on LLOS to my username, password, and PIN, I will have my entire computer there.

281
00:34:52,270 --> 00:35:00,550
I will have my desktop, I will have my files, because it runs through a distributed file system, so you don't necessarily have to have everything locally bound.

282
00:35:00,550 --> 00:35:02,390
You just keep a local cache of that.

283
00:35:02,790 --> 00:35:09,890
And so the kernel then becomes responsible for populating this local cache of the user-level data from this distributed file system.

284
00:35:09,890 --> 00:35:25,350
So I could then go to my other computer and log into my SIG chain, one that has never, ever logged into that SIG chain before, and a very quick synchronization process will start happening in the backend that will be retrieving some of those files that are needed.

285
00:35:25,370 --> 00:35:33,590
And the other important quality is the LLOS out-of-box will work as part of a distributed computing framework.

286
00:35:33,590 --> 00:35:46,510
So if you have, let's say, 100 gigabytes or 200 gigabytes of free disk space, by default you'll be able to actually monetize that disk space through smart contracts, peer-to-peer smart contracts , by hosting data for other people.

287
00:35:46,590 --> 00:35:50,750
So what this creates is it creates a new type of environment.

288
00:35:50,750 --> 00:36:01,810
It's creating a level of indirection on top of the user space that exists now where the user space is in a bit more of a mathematical hyperspace rather than in your local computer.

289
00:36:01,810 --> 00:36:03,410
It's not locally bound.

290
00:36:03,410 --> 00:36:18,090
So you essentially get automatic backups, you get synchronization, and you get higher levels of security because all of the actions required to change your user space's state requires blockchain and cryptographic identifiers and cryptographic verification.

291
00:36:18,230 --> 00:36:25,270
So you get these high levels of security and there really becomes not much to take over on the local device.

292
00:36:25,270 --> 00:36:44,010
There's not, there's nothing there to commandeer because it exists kind of on a more elevated mathematical space so you reduce the attack surface from the actual physical hardware or the operating system into the actual virtualized user space so you'd have to attack the blockchain level information.

293
00:36:44,010 --> 00:36:49,850
You'd have to attack the blockchain subchain in order to try to manipulate and take over that specific computer.

294
00:36:50,550 --> 00:36:59,690
So, this local device will then become decoupled from the user space, making your computer exist in the distributed file system rather than just a local disk cache.

295
00:36:59,690 --> 00:37:15,910
And that also opens the doors, like I was saying earlier, for users to sell some of their actual physical disk space to essentially monetize their empty disk space on their computer and also pay other people to hold some of their collected backups.

296
00:37:15,910 --> 00:37:28,290
So, you get this new type of experience on a computer without the need for backing up any files because the system will exist in a more mathematical universe than a physically bounded universe.

297
00:37:31,170 --> 00:37:37,090
So, the conclusion is we authenticate every user action through this operating system.

298
00:37:37,090 --> 00:37:41,310
We protect against buffer overflow exports and file ejection techniques.

299
00:37:41,310 --> 00:37:48,810
And we do this through virtualizing the user space so the computer exists in a more mathematical hyperspace than on this local disk.

300
00:37:48,890 --> 00:37:55,330
And we're authenticating every device and develop a software-defined router so that every computer becomes a node in this mesh network.

301
00:37:55,330 --> 00:38:09,270
So, part of the design and the architecture is not only to improve the overall operating system security through Nexus OS, but it's also providing people the ability to connect and become a part of this new internet protocol.

302
00:38:09,270 --> 00:38:12,970
That, out of box, we'll just plug and play.

303
00:38:12,970 --> 00:38:28,150
So that the setup and drivers and all of that, the cumbersome setup that comes with setting up a new computer, we want to eliminate all of that while at the same time providing additional security properties to the computer using cryptographic authentication and like I said,

304
00:38:28,150 --> 00:38:45,810
identification and authentication on every level of the stack to become a new type of computing system that really changes the way that we see operating systems and changes the way that people design them and will also drastically change the way we see cyber security,

305
00:38:45,810 --> 00:38:47,890
especially on the operating system level.

306
00:38:49,850 --> 00:38:52,010
Questions and comments, everybody?

307
00:39:36,730 --> 00:39:38,470
Can you guys hear me?

308
00:40:38,650 --> 00:40:48,770
So, this operating system is also designed to be open-source and community-driven and we're building it somewhat as a group.

309
00:40:48,770 --> 00:40:56,790
We have quite a few people that are already getting involved on the early development such as some people from Cisco among others.

310
00:40:57,790 --> 00:41:10,430
So, if any of you would like to get involved on the development and architecture, like I said, we're designing this to be a new type of operating system that eventually can be utilized by most people.

311
00:41:10,730 --> 00:41:32,210
It's something that really extends the use of the computer in a totally different direction and it's also something that ties together with this new internet protocol and like I said, with software-defined routers, it allows us to essentially eliminate most of the hardware requirements that we have on the internet right now to create a more robust system.

312
00:41:32,210 --> 00:41:39,330
So, if there's any of you that find this inspiring or interested, definitely reach out to us.

313
00:41:39,330 --> 00:41:49,970
My email is Colin at Nexus.io and yeah, we'd love to have more people involved if there's some things that you'd like to add to it.

314
00:41:50,330 --> 00:42:18,250
It's a community-driven operating system that eventually we're going to make it with running zero-wine in a type of virtual machine so that you'll be able to execute Windows applications in a safe sandbox environment as a part of helping it integrate and get people kind of off of using Windows but making it an extremely easy-to-use user experience with all these different features and security properties.

315
00:42:18,250 --> 00:42:22,790
It really takes a lot of the erroneous crap out of using a computer.

316
00:42:22,790 --> 00:42:29,050
Right now, if you're not a very sophisticated individual, you'll have a lot of difficulty maintaining the security.

317
00:42:29,050 --> 00:42:35,590
So, this is something that should out-of-box produce that security for someone without all the setup costs.

318
00:42:35,590 --> 00:42:38,830
So, if this is interesting to any of you, definitely reach out.

319
00:42:38,830 --> 00:42:41,290
Again, my name is Colin Kentrell.

320
00:42:41,290 --> 00:42:52,890
My email is colin at nexus.io Like I said, the architectural development of this is very, very close to complete.

321
00:42:52,890 --> 00:43:01,330
And the initial implementation over the next year or two is being designed to run on essentially basic IoT devices and the Cube satellites.

322
00:43:01,350 --> 00:43:10,190
And then a couple years down the road from there, we will be creating the more consumer version of it which is going to create that ease of use and everything like that.

323
00:43:10,190 --> 00:43:20,930
So, if you guys want to get involved on the early formations of this new internet protocol and operating system and blockchain technology, we would definitely love to get you involved.