Stronghold Enhancement Proposal: Procedures Isolation

[felsweg-iota]

SEP: Procedures Isolation

TOC

• Outline
• Motivation
• Reference-Level Explanation
  • Interface
  • Procedures Executor and Runtime Checking
    • Linux
    • Windows
    • Mac
  • Edge Cases
  • Threat Modelling
• Drawbacks
• Prior Art
• Unresolved Questions
• Future Possibilities

---

Outline

The procedures API shall be more generalized by accepting a generic closure. A proposed runtime control flow checker shall ensure the memory isolation of sensitive data and reject and illegal operations on specific memory regions like copying and moving to avoid exposure of sensitive data held inside a vault.

top ^

Motivation

The current procedures API offers great flexibility to work with sensitive data inside a vault, ressembling the architecure of a pipeline with generators ( eg. create keypairs and store the private part inside a target location), processors ( eg. extract the public key from a private key and expose it), and receivers ( derive a child private / public key pair and store it inside a location). Due to security constraints the procedures API cannot allow custom procedures to be run. The risk of exposing stored secrets by supplying a custom procedure would be possible and render the security model obsolete. This restriction brings the burden to Stronghold to always supply required cryptographic procedures.

This proposal shall describe a possible alternative to leverage this burden by providing a standardized interface that accepts a closure to work with sensitive data. Care must be taken for those use cases where some data shall be exposed intentionally like the extraction of a public key. A runtime control flow checker must ensure that exposable data is never stored in a location.

top ^

Reference-Level Explanation

Interface

An interface providing desired functionality might look like this:

struct Client { 
    sentinel : RuntimeSentinel
}

impl Client {

    pub fn execute_procedure<P,S,K>(&self, target_locations: Vec<Location>, target_container : &mut HashMap<K, <Vec<u8>>,  proc : P) -> Result<(), ClientError> where P : Fn(HashMap<K, Location>, S), K : Hash + PartialEq, S : Sentinel {
        // sentinel gives access to locations
    }
}

The following code snipped exemplifies the construction of a closure that accesses secrets on desired location and writes desired output into a generalized container.

fn test_procedure_execution_generate_ed25519_keypair() {
    use iota_stronghold::Stronghold;
    use std::collections::HashMap;
    use crypto::signatures::ed25519;
    
    // This enum is used for demonstration purposes only 
    #[derive(Hash,PartialEq)]
    enum KeyTypes {
        Ed25519PrivateKey,
        Ed25519PublicKey,
    }
    
    // create a default Stronghold instance
    let stronghold = Stronghold::default();
    
    // skip snapshot loading and assume the client is present
    
    let client = stronghold.load_client(b"client-01").expect("Failed to load client by path");
    
    // create an empty container for exposed data 
    let mut container : HashMap<KeyTypes, Vec<u8>> = HashMap::new();
    
    client.execute_procedure(vec![], &mut container, |locations, sentinel| {
        let primary_key = ed25519::SecretKey::generate().map(|sk| sk.to_bytes().to_vec())?
        
        // write the primary key to a location
        sentinel.write(locations.get("location-01"), primary_key);
        
        // this is a sensitive operation as it allocates memory on
        // the stack to store secret data. This operation shown here
        // could be done directly on the primary_key
        let secret_key = sentinel.read(locations.get("location-01"))
        
        // call a function on the return secret structure to obtain
        // some other data. In this case we derive the public key portion
        // from the secret key
        let public_key = secret_key.public();
        
        // this is a sensitive operation, even though it might not 
        // be obvious at first sight. The sentinel must check if the exposed
        // data is allowed to be transfered to the outer container. ideally   
        // every allocated memory region on the stack or heap is encrypted
        // and will be decrypted when transfered. 
        sentinel.transfer(container, (KeyType::Ed25519PublicKey, public_key));
        
    });
    
    // since we transfered the public_key to our container, we can now safely 
    // retrieve it. 
    let public_key = container.get(&KeyType::Ed25519PublicKey);
    
    // print it out ;-)
    println!("{}", public_key);
    
}

top ^

Procedures Executor and Runtime Checking

As briefly introduced the core element for secure closure execution is a component we call a Sentinel. A Sentinel is divided into a plain trait and an actual implementation depending on the operating system.

struct Guard<K> {
    inner : K
}

pub trait Sentinel {
    type Error;
        
    /// This function enables writing data into a desired location. If no
    /// error occurs, it will return an `Ok(())`
    fn write<L, D>(&self, location : L, data : D) -> Result<(), Self::Error> where L : Location, D : AsRef<[u8]>;
        
    /// This functions tries to read from a Location and returns the data 
    /// and encrypted and protected, wrapped up in a `Guard`
    fn read<K>(&self, access : K) -> Result<Guard<K>, Self::Error> where K : Hash + Eq;
    
    /// This function allows the transfer of data out of the trusted zone. If
    /// the origin of the data does not allow transferal, this function
    /// will an error indicating an access violation. 
    fn transfer<A>(&self, acccess : A) -> Result<(), Self::Error> where A : Hash + Eq;
}

top ^

Sentinel Implementation Under Linux Based Systems with Kernel version > 5.x

As security models and utilites vary between major operating systems, this section will focus on the implementation on linux side. A schematic view as shown in fig. 1 displays two security boundaries, the outer boundary is a sentinel that works as a checkpoint for data flows.

_{fig 1.}

An implementation would need to take care of process forking and isolation. forking would be necessary to enforce kernel controlled access flags. The proposed Sentinel should also take care of intercepting system calls. An executing closure shall not be able to leak any information, and only authorized system calls shall be allowed.

System call interception can either be implemented via debugging techniques or by newer platform techniques like eBPF. The latter might require elevated system privileges.

Runtime data flows can be tracked by a technique called taint analysis. The proposed Sentinel must take care of transferable regions of memory. Sensitive data inside the vault must always appear tainted, and shall be denied transfer to so called authenticated memory. The Sentinel would keep shadow memory to store metainformation about tainted data. It is to be decided how many "colors" shall exist. The Stronghold use case might require at least one color (either tainted or not tainted to allow exposing data).

Some definitions on tained data analysis:

• each stored secret inside the vault is tainted
• some secrets may be used to derive publicly available data and may either be not tainted, or tainted with a different color
• memory storage containers are considered TaintedSinks
• sensitive data containers stored in the vault are consideres TaintedSources
• The data flow of tainted data is called Tainted Propagation and must be handled by the Sentinel.

todo: provide some prototypical implementation, highlight the core algorithm

Sentinel Implementation Under Windows > 8.x

prose

Sentinel Implementation Under BSD Based Systems (MacOS)

prose

Procedure Execution from Trusted Network Sources

prose

top ^

Edge Cases

prose

top ^

Threat Modeling

Below is a table of possible attack scenarios with a short description on the use cases given by an attacker.

use-case	privileged access required	threat-level	mitigation
extract secrets via authenticated memory	no	low	Sentinel checks for tainted data
dump sentinel shadow memory	yes	high	Use guarded pages for shadow memory, with severe performance costs

todo: more use-cases

top ^

Drawbacks

Isolating sensitive regions of memory in software is always dependent on the operating systems capabilities. As the awareness grows towards secure software engineering, implementing dextrous methods to keep data safe is always a race against time and malicous actors who will always try to break security restrictions at all costs. This brings us to the usefulness of the described approach that intends to lift some restrictions on Stronghold procedures, but provide the same or higher security guarantees at runtime.

In order to separte the discussion on the drawbacks of the proposed system, we need to separate our concerns between local execution, and remote execution inside a p2p setup.

• discuss execution of local procedures and the enforcement of latest developements on supported chip-hardware security with respect to backwards compatibility
• discuss drawbacks towards the employment of a remote procedure exection in a safe way. What safeguards might not be effective in the future?

top ^

Rationale and Alternatives

The described feature extends the flexibility to work on sensitive data in an isolated and controlled environment, while mitigating, if not excluding any possibility to access sensitive data stored inside the vault. Building secure systems is always bound to a half-life of the actual involved security, thus a current implementation might be breached by some unforseen technique. Many examples from the past have shown that virtually any system can be breached. However, for Stronghold the alternative would be to support and implement custom procedures on a per-demand basis that would bind resources, require careful code inspection and eventually human failure to detect bugs or sensitive information leakage. The proposed functional draws heavy inspiration from other open source projects, but decides to not directly rely on them rather offer corporation and to keep the number of dependencies small. We consider this crucial for an easy adaption on future threats.

top ^

Prior art

We are currently not aware of a similar system setup to execute generic procedures in an isolated environment but matured techniques to mitigate / defend against sophisticated attacks like ROP, Code Injection, Buffer Overflows etc.

top ^

Unresolved Questions

• What is the best approach to enable control flow analysis at runtime?
  • On a local machine where Stronghold is being build from source, macros can enable static code analysis to check correct control flow of supplied closures
  • Windows C++ Compiler enables control flow guards (cfg) via /guard
• What system related methods exists to enforce memory access control?

top ^

Future Possibilities

Use this section to elaborate on future work. Think about how this feature can be progressed. This section is intented to be less strict and can be used to place first ideas.

If you cannot think of any future ideas, just state it here.

Executing procedures could be functionally coupled with a hierarchical permission system. This could either reflect a user's set of permission to access only a subset of secrets. This could be useful for profiles on an integrating application. Other use-cases of a hierarchical permission system could be access and execution from a trusted source over a p2p network.

top ^

Resources

• Intel PIN Dynamic Instrumentation Framework
• Polaris64 Syscall Firewall

[tensor-programming]

discuss execution of local procedures and the enforcement of latest developements on supported chip-hardware security with respect to backwards compatibility

I wonder if we can add a rule to make it so that a remote stronghold can not run a custom proc if the proc doesn't exist on the local stronghold. Aka, if I write a proc for Sr25519 key derivation, if that custom macro isn't in the compiled stronghold that I am trying to access remotely, the proc just fails. It might be safer in general to just not allow custom procs to run on remote vaults but maybe the middle ground would be to have set of options that can turn the capabilities on and off to certain degrees.

[felsweg-iota]

This would be caught by a policy system, or the current "firewall" settings on p2p side. We could think about generalizing this part as well, but that's actually easy to achieve.

With the combination of a policy middle ware + Sentinel execution runtime, serialized operations / executable payloads might still be possible. If there is a way to lock the format of an yet unknown function, we could give the same security guarantees.

[PhilippGackstatter]

Nice proposal! I definitely like how this would make it much easier to do simple operations on keys that currently all require a separate procedure, like a simple concatenation of two secrets.

I'm not sure if I understand the security model completely yet. How does the system distinguish between me calculating the public key to a private key and me base64 encoding the private key? Both are operations on the key and both result in a different sequence of bytes, but one does not allow me to extract the private key while the other does. Is this supposed to be caught by the system and if so, how, or is it up to the procedure implementer to avoid that?

The other part is that the current procedure centralization in Stronghold also has advantages. Namely that the security of the procedures are automatically checked by the stronghold team since it's part of the code base. When each project implements their own cryptographic procedures, the likelihood of bugs is higher. So some alternative for providing shared, common procedures is needed, in my opinion. A stronghold extensions library that implements common procedures might be good. There's certainly a trade-off between having to maintain all the procedures but being able to guarantee a cetain level of security, and the inverse.

System call interception can either be implemented via debugging techniques or by newer platform techniques like eBPF. The latter might require elevated system privileges.

I'm guessing the techniques that don't require elevated privileges would be much preferable? Otherwise the entire binary that stronghold is a part of needs to run with those elevated privileges which seems undesirable and would be a significant hurdle in practice.

[felsweg-iota]

Hi Philipp!
Thank you for the feedback! I will answer directly by quoting you.

I'm not sure if I understand the security model completely yet. How does the system distinguish between me calculating the public key to a private key and me base64 encoding the private key? Both are operations on the key and both result in a different sequence of bytes, but one does not allow me to extract the private key while the other does. Is this supposed to be caught by the system and if so, how, or is it up to the procedure implementer to avoid that?

As of now, this would be the responsibility of the implementer to mark regions intended for transfer as "safe". My idea would be create those memory regions by the Sentinel. From a security point of view, the proposed Sentinel component would require some hardware based trusted execution environment ( TEE). The alternative for Linux based systems (Microsoft is working on it to support it on Windows as well) would be to use eBPF to isolate programs. Using the latter would require elevated privileges, which in turn needs to be considered when using Stronghold in a trusted environment. From my point of view, hardware based memory / trusted execution enclaves are the future and obviously the way to go, as of now purely software based approaches cannot provide the same amount of isolation in a secure way.

The other part is that the current procedure centralization in Stronghold also has advantages.

I partly concur with your argument here, as providing new functionality to Stronghold would require a process to follow up and create more transparency in terms of security. However, even the current procedures system only makes use of software based guards. There is another proposal for hardware secure modules ( HSM ) coming up. The idea would be to coordinate efforts to make the integration seamless.

I'm guessing the techniques that don't require elevated privileges would be much preferable? Otherwise the entire binary that stronghold is a part of needs to run with those elevated privileges which seems undesirable and would be a significant hurdle in practice.

As of now and to the best of my knowledge, anti-debugging techniques would not require elevated privileges. Employing other techniques ( eg eBPF as mentioned above) might require elevated privileges, but come with their own problems when using unprivileged.

---

To summarize my answer a threat model would be required to evaluate the severity of the problems mention above.