What is state-of-the-art-security by design and how does Earth⁶⁴'s data structure provide it?
Building In Security
Security by design is a software engineering concept that implies that a software product has been built from the ground up with security in mind. This means that the software architecture, data structures and algorithms used are selected with the express purpose of optimizing the security properties of the software.
This is in sharp contrast with the still typical approach of designing a software system without security being a primary concern, and passing off the problem of securing the product to a separate static and/or dynamic security analysis (or DevSecOps pipeline), and/or supplying security patches as security flaws are identified.
It is not that security-by-design avoids these approaches, they can remain important to check that software has been implemented properly and to identify and correct for unforeseen vulnerabilities.
The point is that by designing the product from the ground up to ensure optimal security properties, we minimize the attack surface from the outset to eliminate as many known and unknown threats as possible. This radically simplifies security analyses and minimizes or eliminates the need to issue security patches for the product over time.
Security From Simplicity: Proving Valid State
A core piece of the design philosophy for Earth⁶⁴ is to keep things simple by doing one thing really well. This one thing is the ability to prove that the state of an asset is valid. By focusing only on the valid state of an asset, Earth⁶⁴ neither needs to worry about how an asset maintains its integrity (is not double spent or duplicated), nor how the state of an asset is changed and managed (how transactions are performed securely).
This narrowing of concern radically reduces the security considerations that are necessary to take into account. And rather than presenting risks for how state changes are managed, this design gives optimal flexibility to the system developer to choose an integrity and state management system or provider that is most appropriate for their use case. In particular, the most secure integrity and state management system or provider available can be used.
This is possible because Earth⁶⁴ ensures a valid state for assets independently of any blockchain or other service. The ability to prove the state of a Sato-Serer is valid requires establishing two conditions:
The Sato-Server has the correct format and has a valid digital signature; and
The Sato-Server's digital signature was produced by the owner of that Sato-Server.
The first condition is established by checking (i) that the Sato-Server meets the requirements of the Sato-Server specification, which specifies the correct format of all Sato-Servers, and (ii) that the signature is valid based on the claimed owner of the Sato-Server. This entire process is straightforward and its security is very well-understood.
The second condition can always be established if you already know the owner. But it can be established even if you don't know this, provided that the system is implemented according to Earth⁶⁴'s recommendations. In this case, the state management system used will provide a complete proof of provenance of the Sato-Server (or sufficient proof depending on the system design goals of the use case) from its owner at the moment of its creation to its current owner.
The security by design strategy here is to manage as much as possible using a maximally secure procedure (digital signatures) and have the rest handled by other services that specialize in the security of those aspects.
Here, the correctness of the form of the state is completely decidable from two pieces of data: the Sato-Server data and the owner's key. There is no room for security holes here other than those of the digital signature algorithm used (and its software/hardware implementation), since it is algorithmically verifiable from this data that the state has the correct form.
Any remaining uncertainty stems from the question whether the Sato-Server really was signed by the owner, i.e. whether the key in question really is the owner's key. Determining this requires knowing the history of ownership of the Sato-Server, and keeping secure records of the change of state of assets is a problem that is addressed by systems, such as blockchains, that focus on providing this assurance.
Rather than producing yet another solution to this problem and forcing users to rely on it, with Earth⁶⁴ users are free to choose the best system to manage changes of state given their specific design requirements. Moreover, users are free to change to a different, preferable system as it become available or needed.
This last point relates to the question of how Earth⁶⁴ can be not only secure by design by also state-of-the-art-secure.
Why Can Earth⁶⁴ Be State-of-the-art-Secure?
Another dimension of Earth⁶⁴'s security by design is its specification of security functionality rather than specific algorithms or systems. This occurs in two key places (no pun intended).
You may have noticed that I didn't specify which digital signature algorithm is used in Earth⁶⁴. This is because we don't specify this. We only specify how digital signatures need to be used to secure the state of a Sato-Server.
Users are free to choose whichever digital signature algorithm they wish, including those that provide the best, i.e. state-of-the-art, security. If your application requires elliptic curve cryptography, you are free to use that. If you need quantum resistant signature algorithms, you can use those. And if an objectively superior algorithm is developed, you are able to use it.
Earth⁶⁴ has zero dependency on a particular form of hashing, encryption or digital signature algorithm. We specify only the required function of hashes, encryption and digital signatures in the data structure, and not what algorithms or implementations are used.
I also mentioned that we do not require users to manage changes of state using any particular kind of system or service. They are free to run a fully centralized system, a completely decentralized one, or anything in between. As long as they follow our recommended functional requirements for change of ownership records, they will be able to furnish proofs of provenance of the ownership of Sato-Servers to establish the second condition above.
But crucially, they are also free to adopt the most secure system available for managing integrity and transactions of Sato-Servers. This might be some kind of blockchain, but it could also be a different sort of system that has not yet been developed. And just as for cryptography, users are free to change to a more secure system as it becomes available. By specifying only how state changes need to function, not how they are actually accomplished, Earth⁶⁴ permits implementations that have optimal security.
In these ways, Earth⁶⁴'s focus on functional security by design allows the users of the Earth⁶⁴ data structure to achieve security that is state-of-the-art.
In this and the previous article I have discussed how Earth⁶⁴ achieves both security and interoperability by-design. But Earth⁶⁴ also provides confidentiality-by-design, which I will describe in the next article. Stay tuned!