Security
This section provides a description of the security aspects of the BlastShield™ secure network.
BlastShield™ is an in-line IP sub-network within an open IP network that creates a zero-trust protective shield around critical infrastructure assets and data by rendering them undetectable by modern network scanning and traffic analysis tools.A BlastShield network consists of multiple nodes, a node being either a user, Gateway or Agent where each of which is configured for secure, encrypted communication of data over a general network. Each node can automatically discover the presence of the other nodes, determine data communication routes to the other nodes, and establish point-to-point encrypted tunnels between themselves and selected other nodes. The nodes and protected devices are thus organized as a mesh such that the protected devices are undetectable and un-addressable via the general network by entities external to the mesh.
BlastShield™ uses several different security techniques and these are summarized below. They are described more fully in the rest of the document
Users, sessions and devices are identified and authenticated using a public-private key-pairs.
Traffic between nodes is encrypted using AES-256-GCM encryption.
No passwords are used in any part of the system.
Protected end-devices can be rendered un-addressable by unauthorised entities and hence invisible.
The network supports self-opening of connections through NAT devices, which minimises the attack surface. No inbound ports are required to be opened on the firewall.
Node Identification
Nodal identification in the BlastShield™ system is based on public - private key pairs. A key-pair is generated when a new node registers with the BlastShield™ network. Everything that authenticates into the network does so by using digital signatures created by elliptic curve asymmetric keys
All network nodes identify themselves using a combination of a randomized 64-bit node identifier and a 256-bit elliptic curve key-pair.
Key Management and storage
The private key for an end user key-pair is stored within either the secure enclave of an iOS / Android mobile device or a FIDO2-compliant USB key.
On a server, the Host agent private keys are stored locally in the file system with as strict permissions as possible.
The BlastShield™ orchestration node(s) maintains a database of the public keys for all authorized nodes on the network.
Key negotiation and session encryption
When a node (user or secure device) attempts to join the BlastShield™ network it is cryptographically challenged to prove that it is legitimate, and it must show that it can verify a challenge sent by the network. The process for authenticating a new session is described here.
A node connecting to a network fetches the public key and public IP of the network’s orchestration node(s) from a BlastWave hosted service.
For each new connection a new session-temporary elliptic keypair is generated by both nodes. The temporary public keys are then exchanged and verified together with randomized challenges and ECDSA signatures of both the temporary keys, challenges and timestamps.
Two session symmetric keys are then derived from the temporary key pairs using a combination of Diffie-Hellman and HKDF.
Session encryption and authentication is performed using AES-256-GCM. A node is considered authenticated when a message has been sent using the correct symmetric key for the session.
For each new peer connection which a node creates, a new temporary elliptic key pair is generated and exchanged between the peers using the existing tunnel to the orchestration node. Symmetric session keys for the peer connection are then derived using the mechanism described above.
Encrypted peer-to-peer tunnelling
When packets are forwarded between nodes (users, Agents or Gateways) in the BlastShield™ network, the node encrypts the packet using an AES-256-GCM stream cipher and then encapsulates it in a UDP tunnel header before they are sent out to the peer. When it receives the packet, the peer will remove the tunnel encapsulation and decrypt the inner packet. Tunnels are created on-demand and do not require configuration. All tunnelled traffic is peer-to-peer and does not require forwarding via any intermediate device, nor to a proxy of any kind.