cohere-ai/TNG

cohere-ai/TNG

Description: Trusted Network Gateway: A tool for establishing secure communication tunnels in confidential computing.

Language: Rust

License: Apache-2.0

Stars: 2

Forks: 0

Open issues: 11

Created: 2026-03-11T19:13:15Z

Pushed: 2026-06-08T17:59:15Z

Default branch: cohere

Fork: yes

Parent repository: inclavare-containers/TNG

Archived: no

README:

TNG

[](/../../actions/workflows/build-docker.yml) [](/../../actions/workflows/build-rpm.yml) 

[中文文档](README_zh.md)

What is TNG?

TNG (Trusted Network Gateway) is a transparent gateway tool for establishing secure communication tunnels in confidential computing environments. It enables end-to-end encrypted channels by configuring different Ingress and Egress endpoints, automatically verifying the trustworthiness of the communication peer's environment using Remote Attestation mechanisms, all without requiring modifications to existing applications.

Data in Transit Security for Confidential Computing

In confidential computing environments, the security of processing private data is guaranteed by the hardware itself, but data security during network transmission remains insufficient. IETF RFC 9334 standardizes the overall architecture and participant roles for Remote Attestation (RATS), providing a general model for "how to prove an environment is trustworthy." Based on this model, for services running in confidential computing environments, we can use the "instance's own state (including running code and execution environment)" to prove who it is and what environment it is in, rather than just relying on an X.509 certificate. By introducing Remote Attestation into the key exchange process between both parties, combined with appropriate Remote Attestation Policies, we can achieve identity verification and security checks of the server's runtime environment. This approach effectively replaces traditional PKI trust systems, eliminates potential trust weaknesses, and thus bridges the gap in data transmission security in confidential computing scenarios, significantly improving overall security levels.

TNG is designed to package the "Remote Attestation + Encrypted Tunnel" capability based on the RFC 9334 standard into an easy-to-deploy, business-transparent gateway component. As shown in the deployment scenario diagram below, by deploying TNG instances in the trusted domains of both communication parties (configured as Ingress and Egress respectively), peer environment verification and end-to-end data encryption can be automatically completed at the network layer without modifying business code.

graph LR
subgraph ClientEnv [Client Environment]
App[Application]
TNG_In[TNG Ingress]
end

subgraph TrustedEnv ["TEE(TDX / SEV-SNP / CSV)"]
TNG_Eg[TNG Egress]
Service[Business Service]
end

App -- Plain Traffic --> TNG_In
TNG_In -. Remote Attestation + Encrypted Tunnel .-> TNG_Eg
TNG_Eg -- Decrypt & Forward --> Service

style TrustedEnv fill:#ffd700,stroke:#d4af37,stroke-width:2px
linkStyle 1 stroke:#d4af37,stroke-width:2px

Comparison with Other Solutions

• Traditional TLS (PKI): Relies on Certificate Authorities (CA) to issue X.509 certificates for each service, establishing trust through a certificate chain. In practice, certificate application, distribution, installation, and regular rotation are cumbersome. Incorrect configuration or private key leakage can create weak links in the trust chain that are hard to detect promptly. Additionally, these solutions only verify "who the certificate belongs to" and cannot directly reflect whether the current runtime environment is authentic and untampered.
• Various RA TLS Implementations (e.g., [rats-tls](https://github.com/inclavare-containers/rats-tls), [attested_tls](https://github.com/openenclave/openenclave/tree/master/samples/attested_tls)): Usually require manual integration of corresponding libraries into user programs, leading to high integration costs. Configuration can also become very complex when fine-grained verification of the internal software environment is required. TNG can work with the Confidential Containers community's open-source remote attestation components `guest-components` and the remote attestation service `trustee`, supporting fine-grained, configurable remote attestation policy definitions. We also provide built-in RA TLS protocol support, implemented in pure Rust for better security. If you are preparing to use or are already using RA TLS, you can switch to this project without integrating RA TLS libraries in your business code.
• Service Mesh Gateways: Some solutions (like Envoy / Istio combined with SPIFFE) can establish end-to-end TLS tunnels between nodes by issuing X.509 certificates to workloads, but they do not incorporate remote attestation into the root of trust, still primarily relying on the validity of the certificates themselves. In contrast, besides supporting TLS-based tunnels, TNG also supports Oblivious HTTP (OHTTP) for message-level encryption and directly verifies whether the peer runtime environment is trustworthy through remote attestation, making it more suitable for scenarios requiring end-to-end "environment trust + data encryption."

Key Features

• Support for Multiple Encryption Protocols: Provides support for protocols like RA-TLS for arbitrary TCP traffic and Oblivious HTTP (OHTTP) for HTTP message-level encryption, allowing various types of applications to uniformly access the remote attestation-based secure communication system.
• Zero Business Intrusiveness: Through transparent proxy (netfilter) or application-layer proxy (HTTP proxy, Socks5, etc.), TNG avoids changing existing business code and deployment structures, handling plaintext traffic at the network layer into the tunnel with encryption and remote attestation.
• Various Deployment Forms: We provide binary programs, SDKs, and other integration methods to flexibly choose deployment plans based on different business architectures, for example:
• Running as a daemon in VMs or container instances in IaaS scenarios.
• Providing…