WEBVTT 00:00.000 --> 00:04.660 I'm an architect and a software engineer. 00:04.660 --> 00:09.460 I've designed and built the Nexus platform and the TAO framework. 00:09.460 --> 00:15.840 And so I'm here today to discuss with you about security-focused operating system design. 00:15.840 --> 00:22.320 A lot of this has kind of become born with the invention of the blockchain, right? 00:22.320 --> 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. 00:35.080 --> 00:41.660 So this presentation I'm going to discuss exactly how some of these architectural components fit together. 00:42.240 --> 00:48.480 This operating system, LLLOS, is something that has begun development. 00:48.480 --> 00:56.040 So we're just in the final stages of architectural and we're now moving forward into the actual development cycles. 00:56.040 --> 00:58.960 So what is LLLOS? 00:58.960 --> 01:01.180 LLL stands for lower-level library. 01:01.180 --> 01:03.800 So this is a polymorphic template library. 01:03.800 --> 01:05.560 It's developed in C++. 01:05.560 --> 01:11.280 And it's the foundation of the TAO framework and all of the other components of Nexus. 01:11.280 --> 01:16.280 So it contains three main components, the LLC, the LLD, and the LLP. 01:16.420 --> 01:20.760 Otherwise known as lower-level cryptography, lower-level database, and lower-level protocol. 01:20.760 --> 01:29.040 So it's designed to be a standalone template database or template library that you can build different applications on. 01:29.040 --> 01:32.180 One of which is going to be this operating system. 01:32.180 --> 01:37.920 So the lower-level database is a constant-time database, order of one. 01:37.920 --> 01:43.260 So as far as our tests have gotten, we've gotten above a billion keys. 01:43.260 --> 01:46.540 And you have maybe about a 20% reduction in performance. 01:46.540 --> 01:48.500 So that's a very important component. 01:48.500 --> 01:55.360 As we start managing ever-growing datasets for blockchains, we need the database to actually not slow down. 01:55.560 --> 02:00.300 So we've been developing this database specifically over the past four years. 02:00.300 --> 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. 02:08.060 --> 02:13.120 We've been able to get it, like I said, up to a billion keys without actually losing any performance. 02:13.120 --> 02:19.620 The average read performance, random reads, is 180,000 records per second with no memory caching. 02:19.720 --> 02:25.240 The average write performance is 120,000 records per second with no buffering. 02:25.240 --> 02:26.880 That's just straight to the disk. 02:26.880 --> 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. 02:34.160 --> 02:36.280 So this is just checking in the keychain. 02:36.620 --> 02:40.380 So the lower-level database is extremely fast, extremely efficient. 02:40.380 --> 02:47.120 And the beautiful thing is, as the dataset gets larger and larger and larger, you still retain that performance. 02:47.120 --> 02:53.000 So when you get close to a full dataset, it'll go down to about 150,000 random reads per second. 02:53.000 --> 02:58.460 And then the sequential reads end up being about 1.2 million records per second for sequential reads. 02:58.460 --> 03:03.280 So it's a very, very fast, low-level database that's designed for blanching applications. 03:03.280 --> 03:09.140 And it's part of the foundation of this operating system for managing different file clusters and things such as that. 03:09.140 --> 03:14.940 So the lower-level operating system is being designed for authentication up and down the OSI stack. 03:14.940 --> 03:19.380 For those that don't know what the OSI stands for, it stands for Open Systems Interconnection. 03:19.380 --> 03:23.760 And it is somewhat of a template stack that most of the Internet is built on. 03:24.120 --> 03:27.840 And it contains seven layers, which we'll get to on the next slide. 03:28.240 --> 03:32.580 The LLOS is being implemented for cube satellites and IoT devices first. 03:32.580 --> 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. 03:40.580 --> 03:45.120 But the core foundation of it is going to be running on IoT and cube satellites. 03:45.300 --> 03:48.660 And it virtualizes the user space through distributed computing. 03:50.480 --> 03:52.260 So what is Nexus? 03:52.320 --> 03:56.020 So Nexus is a seven-layer software stack as well as the OSI. 03:56.020 --> 04:01.200 And it's designed to interweave with the OSI stack, as you can see. 04:01.200 --> 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. 04:08.560 --> 04:10.020 And this is the OSI. 04:10.120 --> 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. 04:21.600 --> 04:30.140 So this Nexus software stack is designed to, as I said, interweave within the OSI and improve the security properties. 04:30.140 --> 04:34.660 As many of you know, the Internet was not developed with many security properties in mind. 04:34.660 --> 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. 04:49.660 --> 04:53.080 So Nexus is a part of this LLOS. 04:53.080 --> 04:55.440 We'll be running in the kernel space, not the user space. 04:55.440 --> 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. 05:13.780 --> 05:16.880 And you can inject anything into it, and the computer is just going to execute it. 05:16.880 --> 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. 05:24.560 --> 05:28.420 So this fortifies the kernel. 05:28.420 --> 05:31.620 What it does is it allows the kernel to know itself, right? 05:31.620 --> 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. 05:41.660 --> 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. 05:57.200 --> 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. 06:04.940 --> 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. 06:12.680 --> 06:17.300 So a brief explanation of two of the layers of the Nexus software stack. 06:17.300 --> 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. 06:25.180 --> 06:29.200 It's verified through locking mechanisms that are validated through global consensus. 06:29.560 --> 06:34.500 Those are proof-of-stake, proof-of-work, and practical by default-tolerant algorithms. 06:34.500 --> 06:38.020 And it proves ownership and permissions of registers on the layer above. 06:38.580 --> 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. 06:48.920 --> 06:53.160 And they can be transferred, written, or be used as proofs on the operations layer above. 06:53.400 --> 06:58.640 Now, object registers are a type-safe programmable object, allowing the creation of custom data types. 06:58.640 --> 07:02.480 And registers can point to one another, forming relational database models. 07:02.480 --> 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. 07:11.900 --> 07:15.860 The first one is runtime, memory, and binary verification. 07:15.900 --> 07:18.880 The second one is file integrity and Merkle trees. 07:18.880 --> 07:21.580 And then the third one is software-defined routers. 07:21.580 --> 07:26.100 And I'll get to each one of these points as we extrapolate it out further. 07:26.500 --> 07:30.020 So, runtime, memory, and binary verification. 07:30.020 --> 07:32.140 This is to protect against buffer overflows. 07:32.140 --> 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. 07:40.120 --> 07:46.060 Or you do some form of allocation of only a certain aspect of the memory is actually executable. 07:46.060 --> 07:51.680 So that if you have an ROP exploit that does buffer overflow, it makes it very difficult. 07:51.680 --> 07:52.420 Yes. 08:00.910 --> 08:02.810 You're not seeing the changing slide? 08:04.290 --> 08:05.630 Is this better? 08:05.630 --> 08:07.850 Or are you still stuck on the first one? 08:12.080 --> 08:13.600 You can see it now? 08:14.720 --> 08:15.680 Okay. 08:15.940 --> 08:22.020 So, with the runtime, memory, and the binary verification, we're essentially able to start to isolate. 08:22.020 --> 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. 08:28.560 --> 08:36.240 But what we do, especially if we're doing compiling environments, is you have to authenticate any executable code. 08:36.240 --> 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. 08:51.480 --> 08:58.480 And before anything is passed into the CPU, you are able to determine if it was tampered with. 08:58.480 --> 09:04.660 So we authenticate every aspect of the runtime environment, essentially requiring user action to change the kernel state. 09:04.660 --> 09:09.860 We use memory randomization, but more importantly, only small sections of the page memory will be executable. 09:09.860 --> 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. 09:26.120 --> 09:30.260 And I will get to that in a little bit, how the architecture of Nexus works. 09:30.480 --> 09:34.340 But there's a special register that's created when you create a new signature chain. 09:34.340 --> 09:39.520 It contains a number of hashes that correlate to specific public keys. 09:39.640 --> 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. 09:49.640 --> 09:54.500 When you touch the blockchain, it would be generally mutating the state of a register. 09:54.500 --> 09:58.320 So if you're modifying a file, you would have to actually modify the blockchain state. 09:58.320 --> 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, 10:13.380 --> 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. 10:24.600 --> 10:30.020 So any part that is executed will require a user action to change executable memory. 10:30.020 --> 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. 10:46.840 --> 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. 11:03.980 --> 11:09.740 Runtime instructions must be authenticated with the register allocated on Nexus in order to be executed. 11:09.740 --> 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. 11:18.720 --> 11:22.600 So it's the same type of way of hashing your binary before you execute them. 11:22.600 --> 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. 11:33.540 --> 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. 11:45.500 --> 11:50.880 And these checks are going to be happening every so often to ensure that nothing has continued to be tampered with. 11:50.880 --> 11:54.620 Anything that goes to the CPU has to be verified before it runs. 11:54.620 --> 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. 12:02.780 --> 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. 12:24.840 --> 12:29.700 And that's one thing that has created massive security flaws in so many different operating system designs. 12:29.700 --> 12:35.380 But this type of architecture has not been available until the creation of a blockchain. 12:35.580 --> 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. 12:50.780 --> 12:54.760 But in this case, since we have a blockchain, we don't need to rely on all of those. 12:54.760 --> 12:59.480 And trusted platform module version 2.0 has been known to have backdoors to the NSA. 12:59.480 --> 13:02.180 So that's definitely not something that we want to utilize. 13:02.220 --> 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. 13:09.880 --> 13:12.120 And that's another really important distinction. 13:12.120 --> 13:15.660 Because that means that nobody will be able to actually modify the binary. 13:15.660 --> 13:21.340 And before anything is ever executed, it's verified against the register that the developer of the software created. 13:21.340 --> 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, 13:36.020 --> 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. 13:46.020 --> 13:49.400 So file integrity Merkle trees is the second aspect. 13:49.400 --> 13:53.540 So imagine the file system being authenticated using Merkle trees. 13:53.540 --> 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. 14:01.200 --> 14:07.040 So that you can independently verify the integrity of subsets of the file through having the Merkle path. 14:07.180 --> 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. 14:18.160 --> 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. 14:26.220 --> 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. 14:36.820 --> 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. 14:45.640 --> 14:51.240 So this allows independent checking of file integrity on a per block level using Merkle paths. 14:51.240 --> 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. 15:03.200 --> 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. 15:12.640 --> 15:18.080 So what this creates is an immutability quality to the file system and it prevents file system tampering. 15:18.080 --> 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. 15:28.640 --> 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. 15:37.020 --> 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. 15:56.700 --> 16:01.780 So the next one is software-defined routers. 16:01.780 --> 16:08.220 So this is a really important component because Nexus in itself is eventually becoming a new internet protocol. 16:08.220 --> 16:12.820 As you see, we are a software stack similar to the OSI. 16:12.880 --> 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. 16:28.360 --> 16:30.660 And this is where the software-defined routers comes in. 16:30.660 --> 16:35.440 As you guys know, dedicated router hardware is an old technology and it's proving to be ineffective. 16:35.580 --> 16:37.880 IPv6 is a very good example of it. 16:37.880 --> 16:44.240 We've been 20 years since that was actually developed and there's still not IPv6 routes across the internet. 16:44.280 --> 16:48.180 We also have other issues with BGP, which stands for Border Gate Protocol. 16:48.180 --> 16:53.980 Those routing tables can be manipulated and managing a large dynamic state will require a lot of inter-router communication. 16:53.980 --> 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. 17:03.780 --> 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. 17:15.920 --> 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. 17:28.520 --> 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. 17:44.240 --> 17:50.940 So in a conventional IP system, your IP address is both your locator, your physical location. 17:50.940 --> 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. 18:04.280 --> 18:08.820 And so we need authentication up and down the OSI stack. 18:08.820 --> 18:14.480 In a dynamic routing system, it can be stateless, increasing overall security and reducing the ability to spoof routing locators. 18:14.480 --> 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. 18:25.700 --> 18:27.600 So you will always be reachable. 18:27.600 --> 18:31.280 Think of it kind of like a phone number that doesn't change. 18:31.280 --> 18:34.580 When you roam between different cell phone networks, your phone number never changes. 18:34.740 --> 18:36.120 It's only your locator that changes. 18:36.120 --> 18:38.840 So your identifier, aka your phone number, won't ever change. 18:38.840 --> 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. 18:51.860 --> 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. 19:04.580 --> 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. 19:16.700 --> 19:20.940 So a lot of this comes down with a stateless routing system. 19:20.940 --> 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. 19:27.360 --> 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. 19:35.760 --> 19:38.280 So BGP is not something that will work. 19:38.280 --> 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. 20:09.240 --> 20:15.820 So this improves the overall network security because we're not relying on a constantly updating dynamic routing table. 20:15.820 --> 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. 20:24.340 --> 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. 20:37.220 --> 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, 20:50.720 --> 20:52.200 they're n-channel transistors. 20:52.200 --> 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. 20:59.300 --> 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. 21:11.400 --> 21:13.740 So when we're talking about... 21:23.690 --> 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. 21:41.010 --> 21:46.990 In other words, the internet right now only works because ISPs forward traffic for one another. 21:46.990 --> 21:49.430 And it's kind of an unwritten law. 21:49.430 --> 21:51.550 I'll forward for you if you forward for me. 21:51.550 --> 21:53.970 But that's generally only unicast traffic. 21:54.230 --> 21:59.610 Traffic does not generally get forwarded by ISPs because there's no incentive for them to have that. 21:59.610 --> 22:03.010 So the entire internet game theory is slightly... 22:03.890 --> 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, 22:18.730 --> 22:20.010 the initial success. 22:20.010 --> 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. 22:40.490 --> 22:46.810 And that's a really important component because that will discern the difference between an honest node and a dishonest node. 22:46.810 --> 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. 23:12.630 --> 23:17.190 So this reputation is a really important component inside the stateless routing system. 23:17.190 --> 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... 23:29.110 --> 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. 23:41.750 --> 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. 23:52.450 --> 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. 24:07.110 --> 24:10.750 So it needs to be able... 24:10.750 --> 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. 24:24.290 --> 24:29.850 So the locator identifier separation protocol is a really important component to the stateless routing system. 24:29.850 --> 24:36.810 And what it does is it opens us up to create network-level identifiers along with cryptographic identifiers. 24:36.910 --> 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. 24:45.350 --> 24:53.170 So ARP caches will not be able to be corrupted or poisoned in this sense because it will be authenticated. 24:53.170 --> 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. 25:01.150 --> 25:04.070 So authenticate, authenticate, authenticate. 25:04.070 --> 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. 25:12.530 --> 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. 25:25.470 --> 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. 25:42.450 --> 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. 25:53.810 --> 25:56.690 So everything needs to be authenticated. 25:56.690 --> 26:02.950 And now that we have this technology with Nexus and blockchain we can provide these types of authentications. 26:03.150 --> 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. 26:09.190 --> 26:11.570 It only operates because there's trust. 26:11.870 --> 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. 26:21.970 --> 26:28.250 ICANN got a really large donation from Verisign and now Verisign can increase the cost of .com domains ad infinitum. 26:28.250 --> 26:33.870 So those types of issues won't really exist on Nexus because everything's going to be authenticated. 26:33.870 --> 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. 26:43.690 --> 26:50.270 Now, going to the crypto object register again there's another specific hash in there which is for a certificate. 26:50.490 --> 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. 27:05.230 --> 27:14.370 And you can therefore verify with incontrovertible truth that that certificate was generated by the other end user. 27:14.370 --> 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. 27:21.350 --> 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. 27:33.450 --> 27:40.130 So as I was stating earlier, executable memory is going to be treated very, very carefully on the kernel level. 27:40.130 --> 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. 27:47.530 --> 27:56.430 So you will still have security properties or security issues and exploits with social engineering attacks and all of those things. 27:56.430 --> 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. 28:04.810 --> 28:09.310 And the operating system protects against that on many different layers through this authentication. 28:11.270 --> 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. 28:25.210 --> 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. 28:39.670 --> 28:42.390 And that's essentially how we manage accounts on Nexus. 28:42.390 --> 28:45.210 A signature chain is kind of like a personal blockchain. 28:45.210 --> 28:50.590 We give it as a mini blockchain that is a local state or a local scope to that specific user. 28:51.190 --> 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. 29:03.810 --> 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. 29:14.170 --> 29:18.130 And this also allows you to authenticate and verify files that are sent to you. 29:18.150 --> 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. 29:27.030 --> 29:30.370 So this is really important for... 29:30.370 --> 29:33.650 an example would be a smart lock IoT device. 29:34.010 --> 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. 29:45.110 --> 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. 29:53.710 --> 29:56.890 This identifier is the actual user level signature chain. 29:56.890 --> 30:00.370 The device level signature chain is a device level signature chain. 30:00.370 --> 30:06.810 It doesn't necessarily have all of the full range of operations available as a user signature chain. 30:06.810 --> 30:11.070 And obviously you can't apply a device signature chain to own a device signature chain. 30:11.070 --> 30:15.010 So this user signature chain becomes therefore the control of the device. 30:15.010 --> 30:20.170 Now, the device level signature chain is just for authenticating things specific to that device. 30:20.170 --> 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. 30:33.710 --> 30:38.790 There's nothing stored on that device that will be of use to hack. 30:38.790 --> 30:44.750 Because that device level signature chain is going to obey this public signature chain, this user level signature chain. 30:44.750 --> 30:48.030 And it requires that user signature chain in order to have action. 30:48.030 --> 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. 31:00.910 --> 31:05.990 So this gives each device a network identity, as I was saying. 31:05.990 --> 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. 31:13.090 --> 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. 31:24.130 --> 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. 31:42.070 --> 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. 32:04.190 --> 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. 32:28.370 --> 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. 32:54.790 --> 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. 33:06.170 --> 33:09.450 So this ties into device synchronization. 33:09.490 --> 33:13.690 Most IoT devices cannot talk to each other due to incompatible hardware and software. 33:13.890 --> 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. 33:23.490 --> 33:26.490 I gave you guys a quick example of how that all works. 33:26.790 --> 33:33.970 And it also there's one aspect of the API layer that allows you to create peer-to-peer communication. 33:33.970 --> 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. 33:41.370 --> 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. 33:55.070 --> 33:57.250 You have to download something else, you have to install it. 33:57.250 --> 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. 34:03.690 --> 34:07.610 They can kind of get around it, but there's a massive user issue. 34:07.610 --> 34:10.250 And part of that is also just the synchronization problem. 34:10.250 --> 34:19.030 So the Nexus operating system, or LLOS, kind of extends the user space out of the local hardware. 34:19.170 --> 34:19.690 Right ? 34:19.910 --> 34:25.850 It creates a virtualized user space, which I believe is the next slide. 34:26.130 --> 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. 34:36.210 --> 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. 34:42.550 --> 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. 34:52.270 --> 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. 35:00.550 --> 35:02.390 You just keep a local cache of that. 35:02.790 --> 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. 35:09.890 --> 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. 35:25.370 --> 35:33.590 And the other important quality is the LLOS out-of-box will work as part of a distributed computing framework. 35:33.590 --> 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. 35:46.590 --> 35:50.750 So what this creates is it creates a new type of environment. 35:50.750 --> 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. 36:01.810 --> 36:03.410 It's not locally bound. 36:03.410 --> 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. 36:18.230 --> 36:25.270 So you get these high levels of security and there really becomes not much to take over on the local device. 36:25.270 --> 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. 36:44.010 --> 36:49.850 You'd have to attack the blockchain subchain in order to try to manipulate and take over that specific computer. 36:50.550 --> 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. 36:59.690 --> 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. 37:15.910 --> 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. 37:31.170 --> 37:37.090 So, the conclusion is we authenticate every user action through this operating system. 37:37.090 --> 37:41.310 We protect against buffer overflow exports and file ejection techniques. 37:41.310 --> 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. 37:48.890 --> 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. 37:55.330 --> 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. 38:09.270 --> 38:12.970 That, out of box, we'll just plug and play. 38:12.970 --> 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, 38:28.150 --> 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, 38:45.810 --> 38:47.890 especially on the operating system level. 38:49.850 --> 38:52.010 Questions and comments, everybody? 39:36.730 --> 39:38.470 Can you guys hear me? 40:38.650 --> 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. 40:48.770 --> 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. 40:57.790 --> 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. 41:10.730 --> 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. 41:32.210 --> 41:39.330 So, if there's any of you that find this inspiring or interested, definitely reach out to us. 41:39.330 --> 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. 41:50.330 --> 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. 42:18.250 --> 42:22.790 It really takes a lot of the erroneous crap out of using a computer. 42:22.790 --> 42:29.050 Right now, if you're not a very sophisticated individual, you'll have a lot of difficulty maintaining the security. 42:29.050 --> 42:35.590 So, this is something that should out-of-box produce that security for someone without all the setup costs. 42:35.590 --> 42:38.830 So, if this is interesting to any of you, definitely reach out. 42:38.830 --> 42:41.290 Again, my name is Colin Kentrell. 42:41.290 --> 42:52.890 My email is colin at nexus.io Like I said, the architectural development of this is very, very close to complete. 42:52.890 --> 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. 43:01.350 --> 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. 43:10.190 --> 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.