I'm an architect and a software engineer. I've designed and built the Nexus platform and the TAO framework.
And so I'm here today to discuss with you about security-focused operating system design.
A lot of this has kind of become born with the invention of the blockchain, right?
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.
So this presentation I'm going to discuss exactly how some of these architectural components fit together.
This operating system, LLLOS, is something that has begun development.
So we're just in the final stages of architectural and we're now moving forward into the actual development cycles.
So what is LLLOS? LLL stands for lower-level library.
So this is a polymorphic template library. It's developed in C++.
And it's the foundation of the TAO framework and all of the other components of Nexus.
So it contains three main components, the LLC, the LLD, and the LLP.
Otherwise known as lower-level cryptography, lower-level database, and lower-level protocol.
So it's designed to be a standalone template database or template library that you can build different applications on.
One of which is going to be this operating system.
So the lower-level database is a constant-time database, order of one.
So as far as our tests have gotten, we've gotten above a billion keys.
And you have maybe about a 20% reduction in performance.
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.
So we've been developing this database specifically over the past four years.
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.
We've been able to get it, like I said, up to a billion keys without actually losing any performance.
The average read performance, random reads, is 180,000 records per second with no memory caching.
The average write performance is 120,000 records per second with no buffering.
That's just straight to the disk.
And then the average number of keys that can be checked per second is about 630,000 without actually having to read the data.
So this is just checking in the keychain.
So the lower-level database is extremely fast, extremely efficient.
And the beautiful thing is, as the dataset gets larger and larger and larger, you still retain that performance.
So when you get close to a full dataset, it'll go down to about 150,000 random reads per second.
And then the sequential reads end up being about 1.2 million records per second for sequential reads.
So it's a very, very fast, low-level database that's designed for blanching applications.
And it's part of the foundation of this operating system for managing different file clusters and things such as that.
So the lower-level operating system is being designed for authentication up and down the OSI stack.
For those that don't know what the OSI stands for, it stands for Open Systems Interconnection.
And it is somewhat of a template stack that most of the Internet is built on.
And it contains seven layers, which we'll get to on the next slide.
The LLOS is being implemented for cube satellites and IoT devices first.
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.
But the core foundation of it is going to be running on IoT and cube satellites.
And it virtualizes the user space through distributed computing.
So what is Nexus?
So Nexus is a seven-layer software stack as well as the OSI.
And it's designed to interweave with the OSI stack, as you can see.
You have the base layers, the physical layer, and then the data link, and then the network, transport, session, presentation, and application layer.
And this is the OSI.
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.
So this Nexus software stack is designed to, as I said, interweave within the OSI and improve the security properties.
As many of you know, the Internet was not developed with many security properties in mind.
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.
So Nexus is a part of this LLOS.
We'll be running in the kernel space, not the user space.
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.
And you can inject anything into it, and the computer is just going to execute it.
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.
So this fortifies the kernel.
What it does is it allows the kernel to know itself, right?
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.
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.
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.
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.
So a brief explanation of two of the layers of the Nexus software stack.
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.
It's verified through locking mechanisms that are validated through global consensus.
Those are proof-of-stake, proof-of-work, and practical by default-tolerant algorithms.
And it proves ownership and permissions of registers on the layer above.
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.
And they can be transferred, written, or be used as proofs on the operations layer above.
Now, object registers are a type-safe programmable object, allowing the creation of custom data types.
And registers can point to one another, forming relational database models.
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.
The first one is runtime, memory, and binary verification.
The second one is file integrity and Merkle trees.
And then the third one is software-defined routers.
And I'll get to each one of these points as we extrapolate it out further.
So, runtime, memory, and binary verification.
This is to protect against buffer overflows.
Right now, the main ways that we can protect against buffer overflow attacks on the kernel space is to do randomized address creation.
Or you do some form of allocation of only a certain aspect of the memory is actually executable.
So that if you have an ROP exploit that does buffer overflow, it makes it very difficult.
Yes.
You're not seeing the changing slide?
Is this better?
Or are you still stuck on the first one?
You can see it now?
Okay.
So, with the runtime, memory, and the binary verification, we're essentially able to start to isolate.
We take some of the properties of protecting against buffer overflows, such as having a certain portion of the memory being executable.
But what we do, especially if we're doing compiling environments, is you have to authenticate any executable code.
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.
And before anything is passed into the CPU, you are able to determine if it was tampered with.
So we authenticate every aspect of the runtime environment, essentially requiring user action to change the kernel state.
We use memory randomization, but more importantly, only small sections of the page memory will be executable.
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.
And I will get to that in a little bit, how the architecture of Nexus works.
But there's a special register that's created when you create a new signature chain.
It contains a number of hashes that correlate to specific public keys.
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.
When you touch the blockchain, it would be generally mutating the state of a register.
So if you're modifying a file, you would have to actually modify the blockchain state.
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,
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.
So any part that is executed will require a user action to change executable memory.
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.
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.
Runtime instructions must be authenticated with the register allocated on Nexus in order to be executed.
So if I download a new application, the application developer will have a blockchain register
associated with the binary that they created.
So it's the same type of way of hashing your binary before you execute them.
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.
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.
And these checks are going to be happening every so often to ensure that nothing has continued to be tampered with.
Anything that goes to the CPU has to be verified before it runs.
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.
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.
And that's one thing that has created massive security flaws in so many different operating system designs.
But this type of architecture has not been available until the creation of a blockchain.
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.
But in this case, since we have a blockchain, we don't need to rely on all of those.
And trusted platform module version 2.0 has been known to have backdoors to the NSA.
So that's definitely not something that we want to utilize.
So newly downloaded binaries will be authenticated from the developer's signature chain,
requiring authentication before instructions are sent to the CPU.
And that's another really important distinction.
Because that means that nobody will be able to actually modify the binary.
And before anything is ever executed, it's verified against the register that the developer of the software created.
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,
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.
So file integrity Merkle trees is the second aspect.
So imagine the file system being authenticated using Merkle trees.
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.
So that you can independently verify the integrity of subsets of the file
through having the Merkle path.
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.
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.
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.
Because we don't need to worry about file system tampering
because it always requires this register from the blockchain to actually be verified.
So this allows independent checking of file integrity on a per block level using Merkle paths.
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.
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.
So what this creates is an immutability quality to the file system
and it prevents file system tampering.
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.
So the kernel itself will be doing this integrity checking
and it will require specific user action in order to update on the blockchain.
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.
So the next one is software-defined routers.
So this is a really important component because Nexus in itself
is eventually becoming a new internet protocol.
As you see, we are a software stack similar to the OSI.
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.
And this is where the software-defined routers comes in.
As you guys know, dedicated router hardware is an old technology
and it's proving to be ineffective. IPv6 is a very good example of it.
We've been 20 years since that was actually developed
and there's still not IPv6 routes across the internet.
We also have other issues with BGP, which stands for Border Gate Protocol.
Those routing tables can be manipulated and managing a large dynamic state
will require a lot of inter-router communication.
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.
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.
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.
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.
So in a conventional IP system, your IP address is
both your locator, your physical location.
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.
And so we need authentication up and down the OSI stack.
In a dynamic routing system, it can be stateless,
increasing overall security and reducing the ability to spoof routing locators.
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.
So you will always be reachable.
Think of it kind of like a phone number that doesn't change.
When you roam between different cell phone networks,
your phone number never changes. It's only your locator that changes.
So your identifier, aka your phone number, won't ever change.
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.
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.
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.
So a lot of this comes down with a stateless routing system.
So in order to be effective as a new internet protocol,
Nexus needs to handle dynamic routing systems for mesh networks and cube satellites.
As I was touching on that, managing the state,
especially when we have limited bandwidth from satellites and mesh,
is not a viable solution.
So BGP is not something that will work.
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.
So this improves the overall network security
because we're not relying on a constantly updating dynamic routing table.
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.
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.
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, they're n-channel transistors.
So when the bits flip, then you could ruin an entire data set
if you don't have integrity checking on that.
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.
So when we're talking about...
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.
In other words, the internet right now only works
because ISPs forward traffic for one another.
And it's kind of an unwritten law.
I'll forward for you if you forward for me.
But that's generally only unicast traffic.
Traffic does not generally get forwarded by ISPs
because there's no incentive for them to have that.
So the entire internet game theory is slightly...
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,
the initial success.
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.
And that's a really important component
because that will discern the difference
between an honest node and a dishonest node.
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.
So this reputation is a really important component
inside the stateless routing system.
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...
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.
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.
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.
So it needs to be able...
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.
So the locator identifier separation protocol
is a really important component to the stateless routing system.
And what it does is it opens us up to create network-level identifiers
along with cryptographic identifiers.
And this routing system also contains some elements of the OSI
such as ARP, but rather authenticating each device
with their own embedded subchain.
So ARP caches will not be able to be corrupted or poisoned
in this sense because it will be authenticated.
Like I said, everything up and down the OSI stack
needs to be authenticated to provide the security qualities that are required.
So authenticate, authenticate, authenticate.
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.
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.
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.
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.
So everything needs to be authenticated.
And now that we have this technology with Nexus and blockchain
we can provide these types of authentications.
Beforehand, there always was a need for some centralized counterpart
and that's how the Internet's architecture is designed right now.
It only operates because there's trust.
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.
ICANN got a really large donation from Verisign
and now Verisign can increase the cost of .com domains ad infinitum.
So those types of issues won't really exist on Nexus
because everything's going to be authenticated.
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.
Now, going to the crypto object register again
there's another specific hash in there which is for a certificate.
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.
And you can therefore verify with incontrovertible truth
that that certificate was generated by the other end user.
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.
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.
So as I was stating earlier,
executable memory is going to be treated very, very carefully
on the kernel level.
And it will be very, very difficult for you to inject
any instructions that were not created on a user's action.
So you will still have security properties
or security issues and exploits
with social engineering attacks and all of those things.
But what we're doing here is
we're essentially reducing the ability for developers
to make mistakes that open up significant security holes.
And the operating system protects against that
on many different layers through this authentication.
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.
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.
And that's essentially how we manage accounts on Nexus.
A signature chain is kind of like a personal blockchain.
We give it as a mini blockchain
that is a local state or a local scope
to that specific user.
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.
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.
And this also allows you to authenticate and verify
files that are sent to you.
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.
So this is really important for...
an example would be a smart lock IoT device.
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.
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.
This identifier is the actual user level signature chain.
The device level signature chain
is a device level signature chain.
It doesn't necessarily have all of the full range
of operations available as a user signature chain.
And obviously you can't apply a device signature chain
to own a device signature chain.
So this user signature chain becomes
therefore the control of the device.
Now, the device level signature chain
is just for authenticating things specific to that device.
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.
There's nothing stored on that device
that will be of use to hack.
Because that device level signature chain
is going to obey this public signature chain,
this user level signature chain.
And it requires that user signature chain
in order to have action.
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.
So this gives each device
a network identity, as I was saying.
And with it being deterministic
to the device level hardware
that means we'll have unique identifiers
for each one of these devices.
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.
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. 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.
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.
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. So
this operating system is
also a means to standardize
the communication protocols between all
these devices and improve the overall
IoT security.
So this ties into device
synchronization. Most IoT devices
cannot talk to each other due to incompatible
hardware and software. 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. I gave you guys
a quick example of how that all works.
And it also
there's one aspect of the
API layer that allows you to create
peer-to-peer communication. There's also
powerline mesh connectivity, there's local
mesh connectivity, and all these things
that can integrate together and synchronize the devices.
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. You have to download something else, you have to
install it. I mean, even utilizing Linux
it's very difficult for
a non-developer to utilize it, even if you're
using Mint or Ubuntu. They can kind of get around
it, but there's a massive
user issue. And part of that is also
just the synchronization problem. So
the Nexus operating
system, or LLOS, kind of
extends the user space
out of the local hardware.
Right? It
creates a virtualized
user space, which I believe
is the next slide.
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.
It kind of exists to manage
the local device, but also the cache of
the specific virtualized user space is logged
in. 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.
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. You just keep a local cache of that.
And so the
kernel then becomes responsible for populating
this local cache of the user-level data
from this distributed file system.
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. And the
other important quality is
the LLOS out-of-box
will work as part
of a distributed computing framework. 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. So what this creates
is it creates a new type
of environment. 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.
It's not locally bound.
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.
So you get these high levels of security
and there really becomes not
much to take over
on the local device. 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.
You'd have to attack the blockchain subchain
in order to try to manipulate
and take over that specific computer.
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.
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.
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.
So,
the conclusion is we authenticate
every user action through this
operating system. We protect
against buffer overflow exports and file
ejection techniques. And we do
this through virtualizing the user space
so the computer exists in a more
mathematical hyperspace than on this local
disk. And we're authenticating
every device and develop a software-defined
router so that every computer becomes a node
in this mesh network. 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.
That, out of box,
we'll just plug and play. 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, 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,
especially on the operating system level.
Questions and comments, everybody?
Can you guys hear me?
So, this operating system is
also designed to be open-source
and community-driven
and we're building
it somewhat as a group.
We have quite a few people that are already
getting involved on the early development
such as some people from Cisco
among others.
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.
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.
So, if there's any of you that
find this inspiring or interested,
definitely reach out
to us. 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.
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. It really
takes a lot of the erroneous
crap out of using a computer.
Right now, if you're not a very sophisticated
individual, you'll have a lot of difficulty
maintaining the security.
So, this is something that should
out-of-box produce that security
for someone without all the setup
costs. So, if this is interesting
to any of you, definitely reach out.
Again, my name is Colin Kentrell.
My email is colin
at nexus.io
Like I said, the architectural
development of this is
very, very
close to complete.
And the initial implementation over the next
year or two is being designed
to run on essentially basic
IoT devices and the Cube satellites.
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. 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.