#### RFC: 001
#### Authors: Tensor Programming - \<[e-mail]>, Daniel Thompson-Yvetot \<[e-mail]>
# Secure Dynamic Application Delivery System - *Live Document (WIP)*

## Abstract
This document highlights the overarching concepts of a *Secure Dynamic Application Delivery System*. The system employs the use of an **Image/Snapshot** based **Virtual Machine** *e.g. SmallTalk, Dart and Self*, which is wrapped inside of a system specific and unique **Virtual Fingerprint**. In concert with different obfuscation and encryption methods, the VM is able to generate secure applications which can be deployed regardless of system architecture. The images created by the VM can be transplanted from one running VM to another in order to clone the state of the VM to another machine. Images can be posted in encrypted format on a public **DLT** to solidify their legitimacy.

## Details and Implementations

### Virtual Machine

The proposed VM makes use of an *easy to deploy and embedded compiler* *e.g. C/C++, Lua, Lisp, Web Assembly etc*. By doing so the VM may **target any system architecture**. The VM must also be lightweight and relatively fast because of the encryption and obfuscation measures required to make *reverse engineering reasonably improbable*. Due to the use of the **Fingerprint**, the VM must also be *easy to deploy*. This VM will be dynamically generated on each machine. Alternatively, it may also contain a simple API which accepts the Fingerprint data on execution & installation.

### System Fingerprint

A sweep will occur which will identify various metrics regarding the client's machine. This sweep will also include some system entropy and state. This allows for the creation of a Fingerprint which maintains randomness & uniqueness between similar systems and setups. The Fingerprint will use this information to generate an **Environment Key**.

This **Environment Key** allows the VM to create a **unique runtime** for application execution. The VM can partition its virtual memory in a unique pattern based on the generated key. The VM's Assembler Instructions will also be Encrypted by the key until they are called by the **Virtualized System**. By decrypting the instructions at execution time, the hosted applications can stay secure from reverse engineering and tampering. Alternatively, the instuctions could make use of a fully homomorphic encryption algorithm which would allow them to execute tasks without a decryption process. Entropy may also be included during runtime to further obscure execution of hosted applications and any secure data.

### VM Snapshot/Images

The Proposed VM has the ability to generate **Immutable State Snapshots** which are small encrypted and immutable files. These Snapshots can be used to entangle multiple systems together and they can track metrics regarding execution and failure. A running VM can create an instantaneous snapshot of its executing state on demand. These Snapshots will use a provisioned encryption system to allow sections to be decrypted based on the supplied keys.

The core of the snapshot will contain all of the information needed to run a clone of the original VM. The cloning processes allows the VM to effectively sync its state across multiple machines. Application data can also be included in this snapshot to transfer the application between the machines *(1)*. This clone can only be applied to systems with sufficient permissions.

On the fringe of the snapshot, debug information can be exposed to the developers. This debug information contains no information about the user or the client's system to maintain privacy and security. This piece of the Snapshot can either be lightly encrypted using a debug key or exposed publicly depending on the situation. These Snapshots will be small enough to be displayed on a public DLT as data either in a hashed format or an encrypted format.

### Regarding Data Security

All keys and sensitive data can be stored in the VM's Virtualized Registers and Memory Stack. When the runtime shuts down, this data is dropped entirely. The data can be recovered by the VM through the physical snapshot file on the disk. As the runtime executes it may update the fingerprint key based on a periodic sweep of the user's system. Also, upon initial execution the user may enter a password key to further secure their system.

By holding the sensitive information in the registers and stack, runtime applications may derive public keys from this information to allow them to interact with other services. This derivation algorithm must maintain a certain level of cryptologic soundness which can be included in the logic for interacting with the VM's runtime. In this manner, any applications written for the runtime may access the data but not expose it directly.

### Single-use Sealing / Resealing
An interesting approach for "one-time-usage" of snapshot contents could be that when a snapshot is evaluated by the VM, it can have a control flow that executes certain functionality, updates its internal state and concludes by "rewrapping" itself.

#### Considered Technologies and Algorithms
- Fully homomorphic encryption
- Elliptic curve encryption
- Cryptexec: on demand Function Encryption
- Burneye & Burneye2
- Common Lisp
- Lua/C/C++
- Ocaml
- Non-std Rust
- Web Assembly
- Multilinear jigsaw
- Binary Obfuscation

### Document Key:
> #### **Terminology and Acronyms**:
> - Virtual Machine - VM
> - Distributed Ledger Technology - DLT
> - State Snapshot - Image of VM and Applications
> - Key - Environment Key from Fingerprint
> - System Entanglement - Pairing multiple machines
> - Provisioned Encryption System - Permission based Multi-key Encryption.
> #### **Notes:**
> *(1)* A download may have to occur to gain the logic for the application upon acquisition of the snapshot to keep the snapshot from being too large.

## Status of This Memo
This is the Third revision of this memo.
### Changelog
>#### Rev-3
>- added considered technologies and algorithms list
>
>#### Rev-2
>- added information regarding security of highly sensative data.

## Copyright Notice
Copyright (c) 2020 - Tensor Programming ([e-mail]) and the persons identified as the document authors.

All rights reserved.

Code Components extracted from this document must include Simplified BSD License.