Encryption Architecture
Salud Health implements defense-in-depth security with multiple layers of encryption and privacy protection. Medical data is encrypted end-to-end, leveraging Aleo’s zero-knowledge architecture for maximum privacy.Multi-Layer Privacy Model
Layer 1: Client-Side Encryption
Current Implementation (Simplified)
Note: The current MVP uses basic encoding for demonstration. Production deployment should implement proper encryption.Production Encryption (Recommended)
For production deployment, implement AES-256-GCM encryption:Layer 2: Aleo Field Elements
Why Field Elements?
Aleo’s Leo language uses field elements as the fundamental data type. Fields are large prime numbers (approximately 253 bits) that support cryptographic operations.Data Capacity Calculation
Field Element Conversion
Layer 3: Transport Security
HTTPS/TLS Encryption
All communication between frontend and backend uses TLS 1.3:Configuration
Layer 4: Aleo Blockchain Privacy
Private Records
Aleo uses private records for sensitive data. Records are only visible to the owner.Zero-Knowledge Proofs
Aleo uses zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) to enable privacy:Layer 5: Access Control
Cryptographic Access Tokens
Access tokens are cryptographically secure hashes that cannot be guessed or forged.- Collision-resistant: Two different inputs won’t produce the same hash
- Unpredictable: Cannot guess token without all inputs
- Deterministic: Same inputs always produce same hash
- One-way: Cannot reverse hash to find inputs
Access Token Security Analysis
Time-Based Expiration
Access automatically expires based on block height (not wall-clock time):Data Integrity
Hash Verification
Every medical record includes a data_hash for integrity verification:Security Best Practices
For Patients
For Developers
Compliance Considerations
HIPAA Alignment
While Salud is not HIPAA-certified, it implements HIPAA-aligned security controls:| HIPAA Requirement | Salud Implementation |
|---|---|
| Encryption at Rest | ✅ On-chain private records (Aleo encryption) |
| Encryption in Transit | ✅ HTTPS/TLS 1.3 |
| Access Controls | ✅ Cryptographic access tokens |
| Audit Logs | ✅ On-chain access grants (public, immutable) |
| Data Integrity | ✅ Cryptographic hashes (data_hash) |
| Minimum Necessary | ✅ Time-limited access (24h default) |
| Patient Rights | ✅ Patient controls all access grants |
| Revocation | ✅ Manual revocation available |
GDPR Considerations
Right to Erasure (“Right to be Forgotten”): ⚠️ Challenge: Blockchain data is immutable. Once stored, records cannot be deleted. Mitigations:- Encryption: Even if record exists on-chain, it’s encrypted. Destroy key = data unrecoverable
- Off-chain storage: For GDPR compliance, consider storing data off-chain (IPFS) with on-chain hash
- Consent logging: All access grants recorded on-chain (transparent, auditable)
Production Deployment Checklist
Further Reading
Architecture Overview
High-level system architecture
Smart Contract Security
Smart contract security details