0x48piraj / 0x48piraj/wrong8007

Tamper-resilient storage & keying

Ouverte
#3 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub
feature security
Langage dominant
C
Étoiles
20
Forks
0
Métriques de merge des PR
Aucune PR mergée en 30 j

Description

**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)

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Piste de recherche

Le problème décrit l'intégration avec des mécanismes de déclenchement existants (voir le problème #2) et des modules du noyau Linux comme dm-crypt/LUKS. Commencez par examiner le code source du module noyau dans le dépôt pour comprendre le système de déclenchement. Recherchez du code existant de stockage ou de chiffrement. L'objectif est de concevoir une couche de stockage sécurisée qui efface les clés résidant en RAM lors du déclenchement, rendant les données irrécupérables. 'Terminé' signifie une API modulaire qui s'intègre aux déclencheurs et utilise les mécanismes de chiffrement standard de Linux.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
c, linux
Domaine
backend, operating-systems, security
Type d'issue
Fonctionnalité
Difficulté
5/5
Temps estimé
Plus d'une semaine
Activité
À l'abandon
Clarté
Plutôt claire
Accessibilité débutants
25/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.