Data Supremacy From Publisher to Consumer

RAIDA Efficiency

The RAIDA is extremely efficient for many reasons. Its use of quantum-safe AES encryption utilizing the Intel® AES machine instructions reduces the number of CPU cycles needed to encrypt or decrypt to about ten which requires just nanoseconds. This compares to the time it takes most every other server to use quantum-vulnerable TLS key exchange with CPU cycles needed to encrypt and decrypt between 100,000 and 1 million CPU and requiring milliseconds.

The RAIDA software is written in the ‘C’ language which is ten times faster than other languages such as ‘C#’. Reducing the CPU cycles reduces electricity usage, which reduces heat and the need for cooling. Our system reduces power consumption, system weight, battery life, cost of machine, bandwidth usage and length of service.

Guardians

To remove all systemic risk of failure, the RAIDA needs some extra internet infrastructure. Potential failures include these problems:
1. DNS Domains and DNS servers could be compromised causing traffic to be directed away from the RAIDAs and into spoofed RAIDA.
2. If adversaries know the IP addresses of RAIDA servers, the physical location of the RAIDA may be determined leading to a physical attack.
3. If hot-swappable mirrors are implemented, a witness server is needed to help the hot-swappable servers to be promoted to Primaries.

DNS

Sensors need to be able to find the IP addresses of the RAIDA servers that they will be storing data on. Instead of trusting publicly available DNS infrastructure, we use 30 “Guardians” for name resolution. The sensors have the IP Addresses of the 30 Guardians hardcoded into them (RAIDA hints). During initialization, the client pings these Guardians to determine which ones are available. The sensor will then randomly choose three of the Guardians and download a host file from each of them. The host files are compared and if all three match, the IP addresses of the RAIDA and their backup mirrors are accepted. If they do not match, three more are randomly chosen until matches are found.

Proxy Servers

Many of these IP addresses can point to the Guardians themselves. The Guardians can act as reverse proxy servers, routing traffic back and forth to the RAIDA and the Sensors so that the true IP address of the RAIDA servers are unknown to anyone but the Guardians.

Witnesses

If hot-swappable RAIDA are desired then a witness is necessary to ensure that the hot-swappable Mirror Server is synchronized with the Primary and confirm to the hot-swappable Mirror Server that it needs to elevate to Primary. RAIDATech has implemented version 1 of this technology and would further development to create a production ready custom system. In the meantime, off the shelf software provides some alternatives ifø it is needed now.

Internet

UDP vs TCP

The Internet allows for two different transport protocols: TCP and UDP. The UDP protocol is faster than TCP because UDP is “fire and forget” while TCP requires a “handshake” and is a very heavy protocol made to work through nuclear war. Most traffic uses TCP because UDP can lose data. However, because of RAIDATech's Data storage technology, we can afford up to nine of twenty five UDP packets and still be able to read the data. Therefore, we can trade some of our fault tolerance for speed which removes the need for a TCP handshake and shaves a half a second off of each request and response. This and other innovations add up to make RAIDA Data the fastest data storage solution in the world.

For most applications, UPD can only handle 1450 bytes of data before it becomes unusable. UDP can suffer from lost packets, out-of-order packets, dumped packets by routers and return packets being lost. While most UDP programs can only move 1400 bytes at a time reliably, using RAIDA DATA, sensors can move 22.4 KB at a time (1400 bytes per packet x 16 ). If we own all the routers between the sensors and the RAIDA, we can configure them to increase the data sent reliably to a whopping 1 MB at a time.

Sensors & Data Consumers

Sensors are devices located in unsecure locations in risky conditions and face unforeseeable attacks from the most sophisticated advesaries. Data Consumers need accurate knowledge in a timely manner to make intelligent decisions. It is critical that both the Sensors and Data Consumers be secure without suffering from time-lags.

Sensors and Data Consumers Require 25 AES Keys (Advanced Encryption Standard)

Both will have a digital ID in the form of a file containing 430 bytes. This digital ID is composed of a serial number (similar to a driver's license number or SSN) and twenty five unique 128-bit encryption keys. Our custom protocol allows the RAIDA and the sensors to mutually authenticate each other while providing quantum-safe communication. These encryption keys can be changed at any frequency required including on every call to the RAIDA.

Sensors and Data Consumers Use Quantum Safe Encryption

The protocol allows for any type of asynchronistic quantum-safe encryption protocol but uses 128 bit AES as a default. AES 128 allows for suitable encryption at high speeds and low energy use. Most Intel processors have machine commands for AES encryption which reduces processor time to just ten CPU cycles. (Compare this to millions required for TLS)

Sensors Stripe Data and Calculates Parity Stripes. Data Consumers Unite the Stripes

When sensors send data, they will divide the data bit by bit into sixteen different “stripes”. Nine more stripes are calculated for the purpose of fault tolerance and availability. Sensors can send these stripes in a random order to RAIDA severs so long as the Data Consumer also knows the order. See the RAIDA section.

Sensors and Data Consumers May Use Multiple Internet Connections

Both may have multiple connections to the Internet such as cellular, WiFi, terrestrial cable, satellite, and infrared wireless. The sensor can send each stripe out of different network interfaces. By splitting the data into different streams, tapping becomes much more challenging as adversaries will need to combine at least 16 stripes to capture the data. Splitting the streams also adds more bandwidth that can speed up transmissions. (NOTE: Custom Multi Gateway software has not been implemented yet but could be purchased off the shelf)

Sensor And Data Consumer Software

The client software has two components: The GUI and the Client Core. The GUI runs within a web browser and the Client Core is a simple console application. For sensors, only the Core is needed as the GUI is for data consumers. The core is REST-enabled and CLI-enabled. This makes it easy for sensor software written in any language to send data to the RAIDA by making simple API calls to the Client Core. The client software is written in the GoLang language but can be converted to the C++ language to make it faster, more energy efficient and to use less system resources (RAM, Storage, Processor Cycles). Rewriting it in C++ may be a fairly easy job with the help of AI translating the code.

Internet Routers Split Streams

Once those stripes are on the Internet, they will encounter routers that will send packets in different directions depending on where the RAIDA servers are located. Given the fact that our servers are strategically distributed on a global scale, encompassing terrestrial as well as marine and extraterrestrial locations, the routing of the stripes necessitates diverse directional paths. This crucial aspect significantly enhances the complexity for any potential adversary in capturing a sufficient number of stripes, thus reducing their capacity to pose even a minimal threat.

What If An Adversary Was to Successfully Tap 16 Stripes of Data?

If an adversary was to capture all the stripes, they would not know the index numbers of each stream. They would not be able to put the stripes together in the correct order. We calculate that there are over sextillion different combinations should they try to guess.

If they did get them in the correct order, they would need to guess a quantum safe 128 bit key with over a Septillion possibilities. But each stripe is encrypted with a different key. So they would need to decrypt at least sixteen keys so we can multiply that by 16. If they were able to crack those 16, they would not be able to tell that they had decrypted the data because the payload in each stripe will appear as random data.

The RAIDA can block any guessing attempts that it detects and simply refuse to respond to requests. The encryption keys used by RAIDA clients can change every time they are called so that if decryption occurred, they would only get 22 Kilobytes of data. Note: Intrusion detection has not been implemented yet but would be relatively easy to do.

Speed Of Downloading and Uploading Data

The time it takes a Data Consumer to download data from the RAIDA can be as much as sixteen times faster thanks to the striping. Generally speaking, reading and writing from many servers in parallel is multiple times faster than reading or writing from just one server.

Local Storage of Data

In our current implementation, the data files downloaded from the RAIDA ( e.g. PDF, PNG and TXT ) are displayed within browsers. The files are kept in the client’s RAM so that the files will not be compromised if the physical integrity of the client computer is compromised. If the computer is shut down, all files in RAM will be lost. Note: we have the option of encrypting the files in RAM although it has not been implemented.

Physical Security of Sensors

RAIDATech has envisioned a system that uses a 3D printer and a fiber optic cable to create a “Cocoon” around the sensor’s motherboard. The fiber optic cable would be plugged into the motherboard and work off the sensor’s power bus which is powered by an external power supply. In the case of an external power loss, the fiber optics would depend on a rechargeable battery within the cocoon.

This fiber optic cocoon would be impregnated into a resin by using a 3D printer.The cocoon would be woven in such a way that it would be impossible for adversaries to access the sensor’s TMP chip without breaking the fiber optic cable. The motherboard’s CMOS chip would constantly ping the fiber optic cable to detect breakage even when the sensor loses external power. If the CMOS chip detected that the fiber optic cable was broken, the CMOS would delete the sensor’s ID. This would require that the ID be replaced before the sensor could be authenticated by the RAIDA again.