Technical details on Redwall's core technology

Technical details


Redwall security is built into a device at multiple layers, providing security enhancements for each layer as shown in the example below for an Android architecture. RCore wraps the kernel providing a security monitor which performs integrity checking, trusted cryptographic operations, and security policy enforcement. RInit lives in the Android layer to provide mode switching and security policy support. The optional RClient also lives in the Android layer and communicates with the optional policy server, RServer, to download policies, commands, and data, as well to provide logging and phone status.

Redwall secure device architecture
RCore
Rcore runs in a separate security context from the kernel, and guarantees that critical resources have not been modified. It ensures that rogue processes cannot insert privileged code. It also provides cryptography and system logging via an API. RCore monitors all system calls, inspects their parameters, and determines whether or not the call is permitted by the current security policy. It also uses access control lists (ACLs) to regulate file, device, and network address usage.
RInit
RInit augments the startup process (e.g. Android’s Init module) by providing mode-specific policy settings and the ability to switch between modes. On a mode switch, RInit tears down the existing Android instance, and replaces it with a new one that includes only the drivers, partitions, keys, and data appropriate for the new policy. This process provides cryptographic and temporal isolation, keeping one mode from being able to contaminate another.
RClient and RServer
RClient runs as a small Linux daemon or RT task, and communicates with RServer over a secure channel (optionally augmented by TLS). RClient processes requests to upload/download files, wipe data, switch modes, update policies, update cryptographic keys, execute commands, reseed the random number generator, and much more.

RServer is an application for Linux platforms accessed by authorized users and devices over HTTPS. It is completely optional - Redwall does not need to be connected to the policy server to operate. The server can be on VPN, private-cloud, or Internet protected with proxies and web application firewalls (WAFs). The management and administration GUI enables an organization to perform the various tasks associated with provisioning and administering Redwall devices, including:

  • Registration of devices
  • Creation of custom policies
  • Creation of unique device firmware images
  • Installing/uninstalling apps to/from specific modes on devices
  • Sending/receiving files to/from devices
  • Sending commands (mode changes, key changes, etc.) to devices
  • Remotely locking devices and/or wipe data
  • Pushing new/updated/temporary policies to devices
  • Verifying that a device kernel has not been modified (attestation)

A role-based access control allows different administrators the ability to perform different tasks. This facilitates a clear separation of roles during the administration process and enables responsibilities to be easily split among different groups (provisioning, security, attestation, etc.).

Security policies

Each mode on a device is based on a security policy which can be tailored to specific user need or operation context. The policy defines which processes can access which system features, and what the device should do when that policy is first put in place. Only one policy can be active at a time allowing a single device to operate in multiple security contexts. The device switches modes as needed or as directed by a user, the infrastructure (i.e., the policy server), or environment (i.e., geo-fencing). Redwall policies are simpler to create than SELinux/SE Android or other systems, and are stored as signed text files. Everything is configurable, including what security response to take if malicious behavior is detected. A policy can specify items such as:
  • High level access control lists (ACLs) for system resources like the camera, GPS, WiFi, Bluetooth, NFC, etc.
  • File system ACLs
  • Network address ACLs
  • System call ACLs
  • Kernel and file integrity checking parameters
  • Differential power analysis (DPA) countermeasure parameters
  • Violation actions (report, switch modes, data wipe, etc.)

Further details

More technical details and materials are available under a a standard non-disclosure agreement, or under PROPIN classification to government agencies and organizations (including state and local level) in the US, Canada, the UK, Australia, and New Zealand. Please contact us to make arrangements and we will be thrilled to share the information you require.
Did you know...

  • Interested in partnering? Redwall frequently partners with both defense primes and other small businesses.
  • Redwall Mobile can perform attestation on a device, run device-level integrity checks, and take advantage of any trusted boot features.
  • Redwall Mobile can operate with or without a server (MDM) component, and is suitable for tactical, non-connected (disconnected) deployments.
  • Redwall works with industry partners to offer a variety of 8(a) contract vehicles.
  • Redwall Mobile offers performance benefits over virtualization, and a stronger security model than traditional hypervisors.
Redwall Logo