0x48piraj / 0x48piraj/wrong8007

Tamper-resilient storage & keying

Abierto
#3 0 comentarios 0 reacciones 0 asignados Ver en GitHub
feature security
Lenguaje dominante
C
Estrellas
20
Forks
0
Métricas de merge de PR
Sin PR fusionados en 30 d

Descripción

**Description**
Implement a secure, modular storage layer that focuses on **resilience against tampering or post-compromise forensics**. This is not about detecting tamper events, but ensuring that once a trigger fires, **data becomes cryptographically irrecoverable**.

This storage layer should tie into existing trigger mechanisms to wipe RAM-resident keys, making data unreadable even with physical access working alongside tamper detection layers (see #2) for full lifecycle defense.

**Components**

* Ephemeral keying for encrypted storage

* RAM-resident encryption keys (non-persistent)
* Keys wiped on trigger (e.g., keyboard phrase, USB event, network packet)
* Integration with dm-crypt / LUKS volumes

* One-time pad (OTP) or XOR-based multi-layer key splits

* Distribute decryption key into multiple parts
* Require all pieces for full recovery
* Optional: store parts across different locations (e.g., device + remote peer)

**Goals**

* Use standard Linux mechanisms (e.g., dm-crypt, LUKS) where possible
* Abstract encryption/key-wiping logic behind an internal API
* Ensure key material never touches disk or swap
* Optionally: allow key splitting via simple XOR or Shamir's Secret Sharing

**Optional extensions**

* TPM-backed key storage with time-based unlock windows
* Remote key escrow with secure request protocol
* Support for volatile in-memory filesystems (e.g., `tmpfs` + encrypted overlay)

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Línea de trabajo

El issue describe la integración con mecanismos de activación existentes (ver issue #2) y módulos del kernel de Linux como dm-crypt/LUKS. Comience examinando el código fuente del módulo del kernel en el repositorio para comprender el sistema de activación. Busque código existente de almacenamiento o cifrado. El objetivo es diseñar una capa de almacenamiento seguro que borre las claves residentes en RAM al activarse, haciendo que los datos sean irrecuperables. 'Hecho' significa una API modular que se conecte a los activadores y utilice mecanismos de cifrado estándar de Linux.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
c, linux
Área
backend, operating-systems, security
Tipo de issue
Nueva funcionalidad
Dificultad
5/5
Tiempo estimado
Más de una semana
Estado de actividad
Estancado
Claridad
Bastante claro
Aptitud para principiantes
25/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.