start	end	text
0	9460	I'm an architect and a software engineer. I've designed and built the Nexus platform and the TAO framework.
9460	15840	And so I'm here today to discuss with you about security-focused operating system design.
15840	22320	A lot of this has kind of become born with the invention of the blockchain, right?
22320	28440	Other methods of securing the operating system I've seen through methods of logical attestation
28440	33120	that usually use a trusted platform module in order to create different security properties
33120	35080	in the final system in the operating system.
35080	41660	So this presentation I'm going to discuss exactly how some of these architectural components fit together.
42240	48480	This operating system, LLLOS, is something that has begun development.
48480	56040	So we're just in the final stages of architectural and we're now moving forward into the actual development cycles.
56040	61180	So what is LLLOS? LLL stands for lower-level library.
61180	65560	So this is a polymorphic template library. It's developed in C++.
65560	71280	And it's the foundation of the TAO framework and all of the other components of Nexus.
71280	76280	So it contains three main components, the LLC, the LLD, and the LLP.
76420	80760	Otherwise known as lower-level cryptography, lower-level database, and lower-level protocol.
80760	89040	So it's designed to be a standalone template database or template library that you can build different applications on.
89040	92180	One of which is going to be this operating system.
92180	97920	So the lower-level database is a constant-time database, order of one.
97920	103260	So as far as our tests have gotten, we've gotten above a billion keys.
103260	106540	And you have maybe about a 20% reduction in performance.
106540	115360	So that's a very important component. As we start managing ever-growing datasets for blockchains, we need the database to actually not slow down.
115560	120300	So we've been developing this database specifically over the past four years.
120300	128060	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.
128060	133120	We've been able to get it, like I said, up to a billion keys without actually losing any performance.
133120	139620	The average read performance, random reads, is 180,000 records per second with no memory caching.
139720	145240	The average write performance is 120,000 records per second with no buffering.
145240	146880	That's just straight to the disk.
146880	154160	And then the average number of keys that can be checked per second is about 630,000 without actually having to read the data.
154160	156280	So this is just checking in the keychain.
156620	160380	So the lower-level database is extremely fast, extremely efficient.
160380	167120	And the beautiful thing is, as the dataset gets larger and larger and larger, you still retain that performance.
167120	173000	So when you get close to a full dataset, it'll go down to about 150,000 random reads per second.
173000	178460	And then the sequential reads end up being about 1.2 million records per second for sequential reads.
178460	183280	So it's a very, very fast, low-level database that's designed for blanching applications.
183280	189140	And it's part of the foundation of this operating system for managing different file clusters and things such as that.
189140	194940	So the lower-level operating system is being designed for authentication up and down the OSI stack.
194940	199380	For those that don't know what the OSI stands for, it stands for Open Systems Interconnection.
199380	203760	And it is somewhat of a template stack that most of the Internet is built on.
204120	207840	And it contains seven layers, which we'll get to on the next slide.
208240	212580	The LLOS is being implemented for cube satellites and IoT devices first.
212580	220580	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.
220580	225120	But the core foundation of it is going to be running on IoT and cube satellites.
225300	228660	And it virtualizes the user space through distributed computing.
230480	232260	So what is Nexus?
232320	236020	So Nexus is a seven-layer software stack as well as the OSI.
236020	241200	And it's designed to interweave with the OSI stack, as you can see.
241200	248560	You have the base layers, the physical layer, and then the data link, and then the network, transport, session, presentation, and application layer.
248560	250020	And this is the OSI.
250120	261200	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.
261600	270140	So this Nexus software stack is designed to, as I said, interweave within the OSI and improve the security properties.
270140	274660	As many of you know, the Internet was not developed with many security properties in mind.
274660	289440	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.
289660	293080	So Nexus is a part of this LLOS.
293080	295440	We'll be running in the kernel space, not the user space.
295440	313780	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.
313780	316880	And you can inject anything into it, and the computer is just going to execute it.
316880	324560	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.
324560	328420	So this fortifies the kernel.
328420	331620	What it does is it allows the kernel to know itself, right?
331620	341660	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.
341660	357200	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.
357200	364940	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.
364940	372380	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.
372680	377300	So a brief explanation of two of the layers of the Nexus software stack.
377300	385180	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.
385180	389200	It's verified through locking mechanisms that are validated through global consensus.
389560	394500	Those are proof-of-stake, proof-of-work, and practical by default-tolerant algorithms.
394500	398020	And it proves ownership and permissions of registers on the layer above.
398580	408920	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.
408920	413160	And they can be transferred, written, or be used as proofs on the operations layer above.
413400	418640	Now, object registers are a type-safe programmable object, allowing the creation of custom data types.
418640	422480	And registers can point to one another, forming relational database models.
422480	431820	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.
431900	435860	The first one is runtime, memory, and binary verification.
435900	438880	The second one is file integrity and Merkle trees.
438880	441580	And then the third one is software-defined routers.
441580	446100	And I'll get to each one of these points as we extrapolate it out further.
446500	450020	So, runtime, memory, and binary verification.
450020	452140	This is to protect against buffer overflows.
452140	460120	Right now, the main ways that we can protect against buffer overflow attacks on the kernel space is to do randomized address creation.
460120	466060	Or you do some form of allocation of only a certain aspect of the memory is actually executable.
466060	471680	So that if you have an ROP exploit that does buffer overflow, it makes it very difficult.
471680	472420	Yes.
480910	482810	You're not seeing the changing slide?
484290	485630	Is this better?
485630	487850	Or are you still stuck on the first one?
492080	493600	You can see it now?
494720	495680	Okay.
495940	502020	So, with the runtime, memory, and the binary verification, we're essentially able to start to isolate.
502020	508560	We take some of the properties of protecting against buffer overflows, such as having a certain portion of the memory being executable.
508560	516240	But what we do, especially if we're doing compiling environments, is you have to authenticate any executable code.
516240	525880	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,
525880	531480	which will ensure that you know the exact instruction set that is being executed by the CPU.
531480	538480	And before anything is passed into the CPU, you are able to determine if it was tampered with.
538480	544660	So we authenticate every aspect of the runtime environment, essentially requiring user action to change the kernel state.
544660	549860	We use memory randomization, but more importantly, only small sections of the page memory will be executable.
549860	558300	And as I was saying earlier, before we pass anything into the actual CPU, we want to run it through an authentication system,
558300	566120	which is essentially verifying the checksum either on a blockchain register or a digital signature that is verified off of the crypto object register.
566120	570260	And I will get to that in a little bit, how the architecture of Nexus works.
570480	574340	But there's a special register that's created when you create a new signature chain.
574340	579520	It contains a number of hashes that correlate to specific public keys.
579640	585120	So this allows you to do offline verification of identity and verifying specific pieces of data
585120	589580	without having to actually touch the blockchain or create a new blockchain entry.
589640	594500	When you touch the blockchain, it would be generally mutating the state of a register.
594500	598320	So if you're modifying a file, you would have to actually modify the blockchain state.
598320	604000	But if you're just doing basic runtime environments, you have a user action required when you compile it
604000	609720	that will sign that specific bytecode into a checksum to ensure that if any time during the runtime
609720	613380	there is an exploit that happens to overwrite some of the executable memory,
613380	621480	before that is actually executed from a function call, it will have to be verified through the blockchain register,
621480	624600	which will protect any type of remote injection attack.
624600	630020	So any part that is executed will require a user action to change executable memory.
630020	635180	Like I was saying, a user action could be anything from updating the state of a register on the blockchain itself
635180	640900	or using one of the crypto object register keys to sign any piece of data,
640900	646840	which is another form of authentication that does not necessarily require the updating of a register state.
646840	651840	So more persistent level data is going to be updated in registers and more temporary data
651840	658300	such as a recently compiled binary will be just signed as a type of notarization,
658300	663980	which will protect that specifically from being mutated if there's anything bad that happens during runtime.
663980	669740	Runtime instructions must be authenticated with the register allocated on Nexus in order to be executed.
669740	676120	So if I download a new application, the application developer will have a blockchain register
676120	678660	associated with the binary that they created.
678720	682600	So it's the same type of way of hashing your binary before you execute them.
682600	687360	The kernel itself is going to be doing that on every level and verifying that off of a blockchain entry
687360	693540	so that you won't have to necessarily manually go and verify the binary has not been tampered with.
693540	696700	You're going to be able to do that at runtime and it's going to be fully automated
696700	701140	so that any time that you're executing any bytecode on this operating system,
701140	705500	it's going to be fully authenticated to ensure that nothing was tampered with during runtime.
705500	710880	And these checks are going to be happening every so often to ensure that nothing has continued to be tampered with.
710880	714620	Anything that goes to the CPU has to be verified before it runs.
714620	719480	And that's a really important distinction that's going to protect this operating system architecture
719480	722780	from exploits that are currently available on current computers.
722780	726680	Because as I'm sure you guys know, user account control on Windows,
726680	731500	to bypass it, you simply just inject your malware directly into explorer.exe
731500	734740	and it executes that with elevated privileges
734740	738840	because the operating system doesn't know what it was before the virus came in
738840	742340	and it just executes and sends every instruction that's executable to the CPU
742340	744840	without having any levels of discernment.
744840	749700	And that's one thing that has created massive security flaws in so many different operating system designs.
749700	755380	But this type of architecture has not been available until the creation of a blockchain.
755580	762560	The other aspects or trusted assistation, which I've seen, which is another operating system design that I've studied,
762560	768240	use the trusted platform module to create this type of this trust, I guess you can say,
768240	770460	and authentication of different pieces of the data.
770780	774760	But in this case, since we have a blockchain, we don't need to rely on all of those.
774760	779480	And trusted platform module version 2.0 has been known to have backdoors to the NSA.
779480	782180	So that's definitely not something that we want to utilize.
782220	786560	So newly downloaded binaries will be authenticated from the developer's signature chain,
786560	789880	requiring authentication before instructions are sent to the CPU.
789880	792120	And that's another really important distinction.
792120	795660	Because that means that nobody will be able to actually modify the binary.
795660	801340	And before anything is ever executed, it's verified against the register that the developer of the software created.
801340	805460	If you're compiling yourself, then you just do a simple digital signature on the end of the compilation
805460	810900	that then locks and specifically hashes that into a temporary object
810900	816020	that can then be used to determine if any of those instructions change during runtime,
816020	820780	which would be a quick way to detect if there was a buffer overflow or ROP exploit
820780	824640	that was used to try to inject a virus into the executable memory.
826020	829400	So file integrity Merkle trees is the second aspect.
829400	833540	So imagine the file system being authenticated using Merkle trees.
833540	838800	But in a sense, you're going to have every block in the file actually contain a hash
838800	841200	or be a leaf of that hash in the Merkle trees.
841200	845360	So that you can independently verify the integrity of subsets of the file
845360	847040	through having the Merkle path.
847180	849900	And now when you create a new file in your file system,
849900	852920	something that's outside of the scope of the kernel in the user space,
852920	858160	that's going to require a user action, which is going to generate and compute this Merkle root.
858160	862540	And this Merkle root will end up being a data member inside a special object register
862540	866220	that is a pointer to the actual data itself.
866220	871440	So the storage location of the data can be utilizing distributed file systems
871440	873740	or your local file system or anything else like that
873740	876820	with very high levels of security.
876820	878960	Because we don't need to worry about file system tampering
878960	885580	because it always requires this register from the blockchain to actually be verified.
885640	891240	So this allows independent checking of file integrity on a per block level using Merkle paths.
891240	894060	And one reason that we use a Merkle tree and Merkle paths,
894060	897120	instead of hashing the entire file, we can only hash small subsets
897120	900040	so that if you update an aspect of the file,
900040	903200	you don't have to recompute every single hash for every single block.
903200	908040	If you only modify one block, you only need to recalculate the Merkle path and the Merkle root
908040	912240	rather than having to calculate every single leaf hash once again.
912640	915420	So what this creates is an immutability quality to the file system
915420	918080	and it prevents file system tampering.
918080	922020	So viruses and malware won't be able to inject themselves into your file system
922020	924960	because before you open any of the files, it'll check the integrity
924960	928640	and you'll be able to detect very quickly if anything is tampered with.
928640	931420	So the kernel itself will be doing this integrity checking
931420	937020	and it will require specific user action in order to update on the blockchain.
937020	941900	So this gives you a type of multi-layered security properties
941900	945260	because in order to actually attack your physical computer now,
945260	948600	you're going to actually have to attack the cryptography existing on the public network
948600	952260	which increases the difficulty of the attack
952260	955900	and reduces the attack surface down on the operating system level.
956700	961780	So the next one is software-defined routers.
961780	965100	So this is a really important component because Nexus in itself
965100	968220	is eventually becoming a new internet protocol.
968220	972820	As you see, we are a software stack similar to the OSI.
972880	975120	And on our network layer, our physical layer,
975120	978460	we're developing mesh network technology and satellite technology
978460	982520	using ISM frequencies, which are publicly available frequencies,
982520	988360	about 5.8 gigahertz band, in order to turn every single device into a node on the network.
988360	990660	And this is where the software-defined routers comes in.
990660	993580	As you guys know, dedicated router hardware is an old technology
993580	997880	and it's proving to be ineffective. IPv6 is a very good example of it.
997880	1000520	We've been 20 years since that was actually developed
1000520	1004240	and there's still not IPv6 routes across the internet.
1004280	1008180	We also have other issues with BGP, which stands for Border Gate Protocol.
1008180	1011460	Those routing tables can be manipulated and managing a large dynamic state
1011460	1013980	will require a lot of inter-router communication.
1013980	1016480	So when we're talking about a dynamic mesh network
1016480	1019580	and a dynamic low-Earth orbit satellite constellation,
1019580	1023460	conventional routing systems such as BGP just will not work.
1023780	1027020	So this operating system in itself, inside the kernel space,
1027020	1029100	will actually be running a software-defined router
1029100	1033040	so that we can actually update it much quicker
1033040	1035920	than you would be able to access the physical hardware.
1035920	1038860	And what's interesting about it is we'll be able to actually
1040160	1042240	create a stateless routing system
1042240	1045520	that doesn't require a dynamic state to constantly update it
1045520	1048520	and there will be no routing tables that can be manipulated.
1048520	1051540	And then any time there's a type of mapping required,
1051540	1055500	such as an ARP packet or any type of LISP mapping,
1055500	1059520	which LISP stands for Locator Identifier Separation Protocol,
1059520	1062620	which essentially is decoupling the identifier on the network layer
1062620	1064240	from the actual routing locator.
1064240	1068000	So in a conventional IP system, your IP address is
1068000	1070940	both your locator, your physical location.
1070940	1074620	Think of an IP address as a type of machine-readable address
1074620	1078080	to a geographic location, so that when it hits the router
1078080	1081820	and it hops, it knows, okay, I need to go in this specific direction
1081820	1084040	so I'm going to take this route.
1084280	1088820	And so we need authentication up and down the OSI stack.
1088820	1090920	In a dynamic routing system, it can be stateless,
1090920	1094480	increasing overall security and reducing the ability to spoof routing locators.
1094480	1097140	So in LISP terminology, a routing locator
1097140	1101540	is the actual physical location, and then the EID,
1101540	1105700	stands for Endpoint Identifier, is your actual device-level identifier.
1105700	1107600	So you will always be reachable.
1107600	1111280	Think of it kind of like a phone number that doesn't change.
1111280	1112980	When you roam between different cell phone networks,
1112980	1116120	your phone number never changes. It's only your locator that changes.
1116120	1118840	So your identifier, aka your phone number, won't ever change.
1118840	1121660	So each device, including IoT and satellites,
1121660	1124600	will have their own embedded system that uses
1124600	1126860	the Locator Identifier Separation Protocol,
1126860	1131860	which also allows us to connect with the old internet protocols as well.
1131860	1134680	If you happen to have a gateway on that specific node
1134680	1136640	to the old internet protocol,
1136640	1140600	then that can add as another RLOC in the RLOC set,
1140600	1144580	as well as you can have your software-defined routing system.
1144580	1148480	So you'll be able to connect and connect with multiple networks at the same time,
1148480	1151680	which is going to be very important as we're starting to expand out
1151680	1155680	into a full, fully-blown new internet architecture.
1156700	1160940	So a lot of this comes down with a stateless routing system.
1160940	1163440	So in order to be effective as a new internet protocol,
1163440	1167360	Nexus needs to handle dynamic routing systems for mesh networks and cube satellites.
1167360	1169980	As I was touching on that, managing the state,
1169980	1173420	especially when we have limited bandwidth from satellites and mesh,
1173420	1175760	is not a viable solution.
1175760	1178280	So BGP is not something that will work.
1178280	1182800	So Nexus OS or LLOS contains, in the software-defined routing,
1182920	1185860	a stateless routing system where all you will need to know
1185860	1189080	is about the number of nodes that you are around,
1189080	1190900	your nearest nodes, your nearest neighbors,
1190900	1195480	because it can use a GPS-type routing system
1195480	1198660	where you can actually use the natural positioning of things
1199300	1202620	without needing a machine-readable address like an IP address
1202620	1206900	to point and shoot and actually be able to get a fully effective route
1206900	1209240	without each of the nodes having to know anything about each other.
1209240	1211600	So this improves the overall network security
1211600	1215820	because we're not relying on a constantly updating dynamic routing table.
1215820	1218600	And if we wanted to add authentication into that routing table,
1218600	1220640	if we were using, let's say, BGP,
1220640	1222820	it's just going to increase the amount of computing cycles
1222820	1224340	that we're going to need to utilize.
1224340	1226140	And when we're dealing with cube satellites,
1226140	1227740	computing cycles are extremely important
1227740	1230160	because, if any of you are aware,
1230160	1233000	in low-Earth orbit, you're still within the atmosphere,
1233700	1237220	but you have a lot of radiation still.
1237220	1240800	And so what happens is you get a high concentration of beta particles,
1240800	1242520	which are essentially just stray electrons,
1242520	1247140	that end up creating a high concentration in the gate of the transistor,
1247140	1249680	which will flip the bit from a zero to a one
1249680	1252200	because, generally, they're n-channel transistors.
1252200	1256720	So when the bits flip, then you could ruin an entire data set
1256720	1259300	if you don't have integrity checking on that.
1259300	1262260	So you have to have multiple CPUs and multiple sticks of memory
1262260	1266200	and a lot of checksumming on all of the internal state changes on the satellite
1266200	1271400	in order to ensure that no radiation has come and tampered with that specific file.
1271400	1273740	So when we're talking about...
1283690	1288890	router, so that out-of-box, every device that runs this LLLOS
1288890	1291230	will be able to connect to the routing system
1291230	1293630	but also provide value to the routing system
1293630	1296330	because the routing system will not work
1296330	1301010	if there's not gamification in the underlying routing architecture.
1301010	1303910	In other words, the internet right now only works
1303910	1306990	because ISPs forward traffic for one another.
1306990	1309430	And it's kind of an unwritten law.
1309430	1311550	I'll forward for you if you forward for me.
1311550	1313970	But that's generally only unicast traffic.
1314230	1317370	Traffic does not generally get forwarded by ISPs
1317370	1319610	because there's no incentive for them to have that.
1319610	1323010	So the entire internet game theory is slightly...
1323890	1325950	is not properly thought out
1325950	1328390	because the internet, kind of like Bitcoin, was an experiment
1328390	1332290	that grew very quickly and became something predominant in the world
1332290	1335170	and they constantly are spending time trying to catch up
1335170	1338730	and resolve the problem that just became from the success,
1338730	1340010	the initial success.
1340010	1343830	So this routing system needs to have a type of reputation system
1343830	1345210	built into the protocol
1345210	1348990	so that nodes that route for one another
1348990	1352330	end up becoming higher or having a higher reputation
1352330	1354930	and nodes that do not route for one another
1354930	1356170	end up getting a lower reputation
1356170	1358530	which gives them a lower probability of their packets
1358530	1360490	getting forwarded through the routing system.
1360490	1361890	And that's a really important component
1361890	1364110	because that will discern the difference
1364110	1366810	between an honest node and a dishonest node.
1366810	1369590	If somebody comes in just being a leech into the system,
1369590	1372030	they're eventually going to leech themselves into isolation
1372030	1376310	because if they refuse to forward packets for their neighbors,
1376310	1378430	their reputation is going to slowly be reduced
1378430	1381390	to the point where their neighbors will stop forwarding packets for them
1381390	1384070	so they will be disconnected from the mesh network
1384070	1386910	with a lower reputation and unable to route
1386910	1390230	essentially degrading them into just a single device network
1390230	1392630	rather than being able to join the entire network.
1392630	1395210	So this reputation is a really important component
1395210	1397190	inside the stateless routing system.
1397190	1399710	And this is why the locator identifier separation protocol
1399710	1401530	is really important because whether or not
1401530	1404770	I'm routing on the regular IP internet protocol
1404770	1407510	or I'm routing on the Nexus protocol,
1407510	1409110	it's going to be...
1409110	1412430	it's still going to need to have this reputation built into it
1412430	1417230	so that nodes know more about who one another is
1417230	1419090	and they'll all need to have this identifier
1419090	1421650	which is cryptographically enforced.
1421750	1424750	So as I was stating earlier with this crypto object register
1424750	1429550	which contains nine 256-bit hashes of public keys,
1429550	1432450	there's one specific key called the Lisp key.
1432450	1435810	So when I create a new RLOC mapping into the mapping system,
1435810	1438430	I'm essentially going to be registering this RLOC
1438430	1441830	which could be an IP address or it could be an NP address
1441830	1443130	or a Nexus protocol address
1443690	1445710	for the stateless routing system.
1447110	1450750	So it needs to be able...
1450750	1454310	so in order to register this, I need to make a digital signature
1454310	1457310	and sign this RLOC in with my EID
1457310	1460350	and this mapping needs to be stored in state in the network
1460350	1464290	so that they can know specifically where to send packets to me.
1464290	1466890	So the locator identifier separation protocol
1466890	1469850	is a really important component to the stateless routing system.
1469850	1473810	And what it does is it opens us up to create network-level identifiers
1473810	1476810	along with cryptographic identifiers.
1476910	1480150	And this routing system also contains some elements of the OSI
1480150	1483190	such as ARP, but rather authenticating each device
1483190	1485070	with their own embedded subchain.
1485350	1490190	So ARP caches will not be able to be corrupted or poisoned
1490190	1493170	in this sense because it will be authenticated.
1493170	1495610	Like I said, everything up and down the OSI stack
1495610	1499070	needs to be authenticated to provide the security qualities that are required.
1501150	1504070	So authenticate, authenticate, authenticate.
1504070	1507410	As I was saying, every aspect of the stack and the operating system
1507410	1511150	needs to authenticate a user's action through an immutable source of truth
1511150	1512490	which is Nexus.
1512530	1515370	And any changes to the state of the virtualized user space
1515370	1517610	must be accompanied by a digital signature
1517610	1519930	linked to the crypto-object register of the SIG chain
1519930	1522730	or an op-write operation to the register
1522730	1525470	that owns that specific part of the user space.
1525470	1528030	So this means if I update and save a file
1528030	1531890	this file actually needs to have the blockchain entry updated as well
1531890	1534550	so that you can constantly have a history of changes
1534550	1538390	and you'll also have a checksum, both ciphertext and plaintext
1538390	1542450	in order to ensure that the file is not tampered in any way.
1542450	1545630	Because when you allow the file system to have injection happen
1545630	1549070	and executable memory to be run
1549070	1553690	then you essentially create a lot of export opportunities for different hackers.
1553810	1556690	So everything needs to be authenticated.
1556690	1559750	And now that we have this technology with Nexus and blockchain
1559750	1562950	we can provide these types of authentications.
1563150	1566670	Beforehand, there always was a need for some centralized counterpart
1566670	1569190	and that's how the Internet's architecture is designed right now.
1569190	1571570	It only operates because there's trust.
1571870	1574410	And that model works to a certain degree
1574410	1577010	but it doesn't scale out very far
1577010	1581910	and it also has corruption issues as we've seen with ICANN and Verisign.
1581970	1584310	ICANN got a really large donation from Verisign
1584310	1588250	and now Verisign can increase the cost of .com domains ad infinitum.
1588250	1591190	So those types of issues won't really exist on Nexus
1591870	1593870	because everything's going to be authenticated.
1593870	1596290	You're not going to be able to just masquerade
1596290	1599470	and you're not going to be able to pollute a centralized authority
1599470	1603650	because Nexus becomes that incontrovertible port of truth.
1603690	1606370	Now, going to the crypto object register again
1606370	1610270	there's another specific hash in there which is for a certificate.
1610490	1612190	So this is another really important distinction
1612190	1616310	because we can actually, in the Diffie-Hellman key exchange
1616310	1619070	we can actually hash that certificate that they give us
1619070	1622370	and do a blockchain lookup to their blockchain identifier
1622970	1625110	which we call a Genesis ID.
1625230	1629310	And you can therefore verify with incontrovertible truth
1629310	1634370	that that certificate was generated by the other end user.
1634370	1636210	So you don't have man in the middle attacks
1636210	1638110	and you don't need to have a public key database
1638110	1641350	which is essentially what a certificate authority is.
1641350	1645350	So executable instructions must be verified to a blockchain register
1645350	1649150	or digitally signed binary compiled before passing to the CPU
1649150	1651450	to protect against buffer overflow exploits
1651450	1653450	or malware injection into the local files.
1653450	1655450	So as I was stating earlier,
1655450	1658530	executable memory is going to be treated very, very carefully
1658530	1660130	on the kernel level.
1660130	1663370	And it will be very, very difficult for you to inject
1663370	1667530	any instructions that were not created on a user's action.
1667530	1671490	So you will still have security properties
1671490	1673830	or security issues and exploits
1673830	1676430	with social engineering attacks and all of those things.
1676430	1677790	But what we're doing here is
1678390	1681150	we're essentially reducing the ability for developers
1681150	1684810	to make mistakes that open up significant security holes.
1684810	1686690	And the operating system protects against that
1686690	1689310	on many different layers through this authentication.
1691270	1694810	So device level identification is another really important distinction
1694810	1697050	and this ties in with the IoT devices
1697050	1700670	because we need an unforgeable device level authentication
1700670	1703330	that allows easy identification of the device,
1703590	1704990	especially for IoT.
1705210	1706830	So what we're doing is
1706830	1709210	we're taking a device level identification
1709910	1713550	from deterministic hardware inputs such as IMEI
1713550	1715090	or anything that you can utilize
1715090	1718110	to generate a cryptographic identity
1718110	1719670	which is called the signature chain.
1719670	1722390	And that's essentially how we manage accounts on Nexus.
1722390	1725210	A signature chain is kind of like a personal blockchain.
1725210	1726210	We give it as a mini blockchain
1726210	1728950	that is a local state or a local scope
1728950	1730590	to that specific user.
1731190	1732910	So when we tie this in
1732910	1735070	with the locator identifier separation protocol,
1735070	1736970	you get this unique identifier
1736970	1738770	as a cryptographic identifier
1738770	1741390	that you can use as a lookup into the global state
1741390	1743810	and the blockchain, essentially.
1743810	1746010	Or you can use it as a network level identifier
1746010	1747790	that will allow you to do a lookup
1747790	1750130	on the specific person that you are communicating with
1750130	1751990	and decide whether or not
1751990	1754170	you want to accept anything from them.
1754170	1756210	And this also allows you to authenticate and verify
1756210	1758130	files that are sent to you.
1758150	1760650	So this gives each device a network identity
1760650	1762110	that exists in the kernel space
1762110	1764490	and is therefore immutable and tied deterministically
1764490	1766770	to the device level hardware identifiers.
1767030	1770370	So this is really important for...
1770370	1773650	an example would be a smart lock IoT device.
1774010	1776730	So this device itself would be running LLOS
1776730	1779290	and it would have a device level signature chain
1779290	1782110	so it has a cryptographic identity on Nexus
1782110	1784870	that can be verified by any individual.
1785110	1787690	And when you first start the device
1787690	1789810	it's going to require some sort of binding
1789810	1791670	where you're going to bind the device
1791670	1793590	to another identifier.
1793710	1796890	This identifier is the actual user level signature chain.
1796890	1798630	The device level signature chain
1798630	1800370	is a device level signature chain.
1800370	1803110	It doesn't necessarily have all of the full range
1803650	1806810	of operations available as a user signature chain.
1806810	1809850	And obviously you can't apply a device signature chain
1809850	1811070	to own a device signature chain.
1811070	1813130	So this user signature chain becomes
1813130	1815010	therefore the control of the device.
1815010	1816670	Now, the device level signature chain
1816670	1820170	is just for authenticating things specific to that device.
1820170	1821690	The user level signature chain
1821690	1823630	will exist outside of that device
1823630	1826390	which essentially reduces the capacity
1826390	1828790	for you to be able to hack IoT devices
1828790	1831150	because the device itself will have
1831150	1833370	nothing of value to hack.
1833710	1835990	There's nothing stored on that device
1835990	1838790	that will be of use to hack.
1838790	1840410	Because that device level signature chain
1840410	1843390	is going to obey this public signature chain,
1843390	1844750	this user level signature chain.
1844750	1846730	And it requires that user signature chain
1846730	1848030	in order to have action.
1848030	1850890	So the attack surface gets greatly reduced
1850890	1852810	from the actual hardware in the device itself
1852810	1855990	and it becomes more of a cryptographic attack
1855990	1856970	on the actual blockchain
1856970	1859350	in order to overtake some of these devices
1859350	1860850	and access them.
1860910	1863650	So this gives each device
1863870	1865990	a network identity, as I was saying.
1865990	1867590	And with it being deterministic
1867590	1868990	to the device level hardware
1868990	1871650	that means we'll have unique identifiers
1871650	1873090	for each one of these devices.
1873090	1874910	Now, each one of these devices will then also
1874910	1877490	have their own unique IP address
1877490	1878750	or crypto EID
1878750	1880290	which will be the identifier
1880740	1882370	so that we'll start to be able to identify
1882370	1884130	each device individually.
1884130	1887270	So in the example of SmartLock
1887270	1888990	you get the device
1888990	1890890	you set up the device
1890890	1892370	by creating the owner
1892370	1894390	the owner of the device would be
1894390	1896830	the user level signature chain, public signature chain
1896830	1898550	which can be done via
1898870	1900210	a register that's created
1900590	1902530	on the device. Now,
1902530	1904210	if I have another specific user
1904730	1906490	somebody that is coming to my house
1906490	1907810	let's say at 5 o'clock PM
1907810	1910810	I can set on the device
1910810	1912670	itself or the user level signature chain
1912670	1914810	I create a type of contract
1914810	1916510	that says this device
1916510	1918650	allows this specific
1918650	1920490	identifier to open my door
1920490	1922470	one time at this specific
1922470	1924190	time stamp in the future.
1924190	1925790	So that that user
1925790	1927910	having another user level signature chain
1927910	1929690	will go to the actual lock
1929690	1931390	and through near field communication
1931390	1933410	will send a digital signature
1934190	1934490	signed
1936230	1937750	from one of the
1937750	1940110	hashed public keys in their crypto object register
1940110	1942170	which is tied to that identifier
1942170	1944190	that cryptographic identifier so the device
1944190	1946270	can authenticate this person is this person
1946270	1948370	cryptographically and then the door can open.
1948370	1949890	So you create this very
1949890	1951990	interesting type of usage of IoT
1951990	1953650	devices and also a consistent
1953650	1955970	standardization between different devices
1955970	1957550	as I'm sure all of you are aware
1957550	1959650	IoT devices have no standards
1959650	1961910	they have very weak security
1961910	1963450	there's not, there's
1963870	1965690	a lot of explosion
1965690	1967870	in the development of them but not
1967870	1970030	as much understanding
1970030	1971510	of the security properties kind of like
1971510	1973830	the internet was or still
1973830	1975510	is. So
1975510	1977890	this operating system is
1977890	1980210	also a means to standardize
1980210	1982050	the communication protocols between all
1982050	1984210	these devices and improve the overall
1984210	1985690	IoT security.
1986170	1988270	So this ties into device
1988270	1990410	synchronization. Most IoT devices
1990410	1992230	cannot talk to each other due to incompatible
1992230	1994090	hardware and software. So
1994090	1996210	LLOS is essentially
1996430	1998350	a framework for developers to easily synchronize
1998350	2000350	IoT devices, allocate control of them
2000350	2002490	to a master SIG chain that's authenticated
2002490	2004130	through Nexus. I gave you guys
2004350	2006490	a quick example of how that all works.
2006790	2008170	And it also
2008170	2010090	there's one aspect of the
2010090	2012370	API layer that allows you to create
2012370	2014390	peer-to-peer communication. There's also
2014390	2016450	powerline mesh connectivity, there's local
2016450	2018370	mesh connectivity, and all these things
2018370	2021090	that can integrate together and synchronize the devices.
2021370	2022430	I sometimes, if I
2022430	2024370	need to send a file from one computer to
2024370	2026290	another computer, the operating system
2026290	2028450	there's some with Apple, with AirDrop
2028450	2030110	and stuff, but there's not
2030110	2032370	very many, very easy
2032370	2034470	to use device synchronization
2034470	2036490	protocols. You have to download something else, you have to
2036490	2038430	install it. I mean, even utilizing Linux
2038430	2040470	it's very difficult for
2040610	2042450	a non-developer to utilize it, even if you're
2042450	2044590	using Mint or Ubuntu. They can kind of get around
2044590	2046510	it, but there's a massive
2046510	2048570	user issue. And part of that is also
2048570	2050410	just the synchronization problem. So
2050410	2052550	the Nexus operating
2052550	2054450	system, or LLOS, kind of
2054450	2055750	extends the user space
2056330	2059030	out of the local hardware.
2059170	2060370	Right? It
2060370	2062830	creates a virtualized
2062830	2064370	user space, which I believe
2064370	2065850	is the next slide.
2066130	2068370	It is not bound to the physical hardware, so
2068370	2070330	it changes the idea of how we
2070330	2072370	see a kernel, rather than actually being something
2072370	2073150	that is
2074450	2076210	managing just that local device.
2076210	2078050	It kind of exists to manage
2078050	2080090	the local device, but also the cache of
2080090	2082150	the specific virtualized user space is logged
2082150	2083910	in. So if I go
2083910	2086150	to, let's say, my desktop, and I
2086150	2087890	log in on LLOS
2087890	2090310	to my username, password, and PIN,
2090310	2092270	I will have my entire computer there.
2092270	2094050	I will have my desktop, I will have my files,
2094050	2095890	because it runs through a distributed
2095890	2097930	file system, so you don't necessarily
2097930	2100070	have to have everything locally
2100070	2102390	bound. You just keep a local cache of that.
2102790	2103690	And so the
2103690	2105830	kernel then becomes responsible for populating
2105830	2107770	this local cache of the user-level data
2107770	2109890	from this distributed file system.
2109890	2111850	So I could then go to my other computer
2111850	2113630	and log into my SIG chain,
2113630	2115910	one that has never, ever logged
2115910	2117650	into that SIG chain before, and
2118090	2119690	a very quick synchronization
2119690	2121630	process will start happening in the backend
2121630	2123770	that will be retrieving some of
2123770	2125770	those files that are needed. And the
2125770	2127170	other important quality is
2127890	2129810	the LLOS out-of-box
2129810	2131850	will work as part
2131850	2133690	of a distributed computing framework. So
2134690	2136030	if you have,
2136030	2137870	let's say, 100 gigabytes or 200 gigabytes
2137870	2140090	of free disk space, by default
2140090	2142190	you'll be able to actually monetize that
2142190	2144470	disk space through smart contracts, peer-to-peer
2144470	2146510	smart contracts, by hosting data for other
2146590	2147650	people. So what this creates
2147650	2149690	is it creates a new type
2149690	2151930	of environment. It's creating a
2151930	2153870	level of indirection on top of the user
2153870	2156130	space that exists now where the user space
2156130	2158010	is in a bit more of a
2158010	2159810	mathematical hyperspace
2159810	2161850	rather than in your local computer.
2161850	2164070	It's not locally bound.
2164070	2166270	So you essentially get automatic backups,
2166270	2168070	you get synchronization, and you
2168070	2170090	get higher levels of security because
2170090	2172370	all of the actions required to change
2172370	2174790	your user space's state requires
2174790	2176030	blockchain and cryptographic identifiers
2176030	2178090	and cryptographic verification.
2178230	2180230	So you get these high levels of security
2180230	2182170	and there really becomes not
2182170	2184130	much to take over
2184130	2185990	on the local device. There's not, there's
2185990	2188150	nothing there to commandeer because
2188150	2190410	it exists kind of on a more elevated
2190410	2191830	mathematical space
2191830	2194110	so you reduce the attack surface from the
2194110	2196150	actual physical hardware or
2196150	2197290	the operating system
2197950	2200250	into the actual virtualized user space
2200250	2201610	so you'd have to attack
2201610	2204010	the blockchain level information.
2204010	2205910	You'd have to attack the blockchain subchain
2205910	2207710	in order to try to manipulate
2207710	2209850	and take over that specific computer.
2210550	2212310	So, this local device
2212310	2213870	will then become decoupled
2213870	2216150	from the user space, making your computer exist
2216150	2217450	in the distributed file system
2217950	2219690	rather than just a local disk cache.
2219690	2221990	And that also opens the doors, like I was saying
2221990	2224010	earlier, for users to
2224010	2226330	sell some of their actual physical disk space
2227010	2227530	to
2227530	2229910	essentially monetize their empty
2229910	2231930	disk space on their computer and also
2231930	2233350	pay other people to
2233710	2235910	hold some of their collected backups.
2235910	2238050	So, you get this new type
2238050	2239810	of experience on a computer
2239810	2242030	without the need for backing up any
2242030	2243850	files because the system will
2243850	2246050	exist in a more mathematical universe
2246050	2248290	than a physically bounded universe.
2251170	2252070	So,
2252070	2254090	the conclusion is we authenticate
2254090	2255870	every user action through this
2255870	2257870	operating system. We protect
2257870	2259730	against buffer overflow exports and file
2259730	2261910	ejection techniques. And we do
2261910	2263690	this through virtualizing the user space
2263690	2265890	so the computer exists in a more
2265890	2267890	mathematical hyperspace than on this local
2267890	2269830	disk. And we're authenticating
2269830	2271810	every device and develop a software-defined
2271810	2273990	router so that every computer becomes a node
2273990	2275710	in this mesh network. So,
2275710	2277910	part of the design and the architecture is
2277910	2279910	not only to improve the overall operating
2279910	2281830	system security through Nexus
2281830	2283890	OS, but it's also
2283890	2285950	providing people the ability to
2285950	2287930	connect and become a part of this new
2287930	2289270	internet protocol.
2289270	2291350	That, out of box,
2291350	2293350	we'll just plug and play. So that
2293350	2295310	the setup and drivers
2295310	2297370	and all of that, the cumbersome setup
2297370	2299270	that comes with setting up a new computer,
2299270	2301290	we want to eliminate all of that while at the same
2301290	2303170	time providing additional security
2303170	2305370	properties to the computer using
2305370	2307430	cryptographic authentication and
2307430	2309490	like I said, identification and
2309490	2311230	authentication on every level
2311230	2313250	of the stack to become
2313890	2315230	a new type of computing
2315850	2317310	system that really
2317310	2319290	changes the way that we see operating systems
2319290	2321290	and changes the way that people design them
2321290	2323350	and will also drastically change
2323350	2325810	the way we see cyber security,
2325810	2327890	especially on the operating system level.
2329850	2332010	Questions and comments, everybody?
2376730	2378470	Can you guys hear me?
2438650	2440390	So, this operating system is
2440390	2442430	also designed to be open-source
2442430	2443610	and community-driven
2444850	2446430	and we're building
2446430	2448770	it somewhat as a group.
2448770	2450810	We have quite a few people that are already
2450810	2452450	getting involved on the early development
2453070	2454650	such as some people from Cisco
2455350	2456790	among others.
2457790	2458990	So, if any of you
2458990	2461590	would like to get involved on the development and architecture,
2461590	2462750	like I said, we're designing
2462750	2465170	this to be a new type of operating system
2465670	2466150	that
2466690	2468750	eventually can be utilized by
2468750	2470430	most people.
2470730	2472850	It's something that really extends
2472850	2474750	the use of the
2474750	2476550	computer in a totally different direction
2476550	2478430	and it's also something that
2478430	2480790	ties together with this new internet protocol
2480790	2483010	and like I said, with software-defined
2483010	2484450	routers, it allows us to
2484450	2486650	essentially eliminate
2486650	2488890	most of the hardware requirements that we have
2488890	2489950	on the internet right now
2490410	2492210	to create a more robust system.
2492210	2494350	So, if there's any of you that
2494350	2496650	find this inspiring or interested,
2496650	2498550	definitely reach out
2498550	2500670	to us. My email is
2500670	2502630	Colin at Nexus.io
2502630	2504590	and yeah,
2504590	2506690	we'd love to have more people
2506690	2508690	involved if there's some things that you'd
2508690	2509970	like to add to it.
2510330	2511930	It's a community-driven
2512510	2514710	operating system that eventually
2514710	2516590	we're going to make it
2516590	2518850	with running zero-wine
2518850	2520530	in a type of virtual machine
2520530	2522750	so that you'll be able to execute Windows applications
2522750	2524650	in a safe sandbox
2524650	2526570	environment as a part
2526570	2528690	of helping it integrate and get
2528690	2530410	people kind of off of using Windows
2530410	2532630	but making it an extremely
2532630	2534730	easy-to-use user experience
2534730	2536670	with all these different features and
2536670	2538610	security properties. It really
2538610	2540810	takes a lot of the erroneous
2540810	2542790	crap out of using a computer.
2542790	2544930	Right now, if you're not a very sophisticated
2544930	2546670	individual, you'll have a lot of difficulty
2546670	2549050	maintaining the security.
2549050	2550610	So, this is something that should
2550610	2552750	out-of-box produce that security
2552750	2554790	for someone without all the setup
2554790	2556810	costs. So, if this is interesting
2556810	2558830	to any of you, definitely reach out.
2558830	2561290	Again, my name is Colin Kentrell.
2561290	2563250	My email is colin
2563250	2564750	at nexus.io
2565290	2566970	Like I said, the architectural
2566970	2568370	development of this is
2569120	2570110	very, very
2571250	2572890	close to complete.
2572890	2574950	And the initial implementation over the next
2574950	2576990	year or two is being designed
2576990	2578910	to run on essentially basic
2578910	2581330	IoT devices and the Cube satellites.
2581350	2583030	And then a couple years down the road
2583030	2584910	from there, we will be creating
2584910	2586410	the more consumer version of it
2586410	2588910	which is going to create that ease of
2588910	2590890	use and everything like that. So, if you
2590890	2592770	guys want to get involved on the
2592770	2594770	early formations of this new
2594770	2596430	internet protocol and operating system
2596430	2598590	and blockchain technology, we would definitely
2598590	2600930	love to get you involved.