SECURITY
Effective February 20, 2026
·
Review February 20, 2027
·
Security Lead
Cryptography Standard
Organization: Aina Design Corp
Applies To: hawaii.mokunet.us · kuleana.ainadesign.org · huikoeaina.ainadesign.org · ainadesign.org
Version: 1.0
Effective Date: February 20, 2026
Next Review: February 20, 2027
Policy Owner: Security Lead
1. Purpose
This standard defines the cryptographic controls required to protect student data and other sensitive information in transit and at rest across all Aina Design Corp platforms. It ensures protection is consistent, auditable, and aligned with current security best practices.
2. Scope
This standard applies to all systems, services, and integrations that store or transmit data on behalf of Aina Design Corp or its district partners.
3. Encryption in Transit
All data transmitted between clients and Aina Design Corp services must use:
Requirement
Standard
Protocol
TLS 1.2 minimum; TLS 1.3 preferred
Certificate Authority
Trusted public CA (e.g., Let’s Encrypt, Google Trust Services)
Certificate Validity
Auto-renewed; no expired certificates in production
Cipher Suites
Only AEAD suites; no RC4, DES, or 3DES
HSTS
Enabled on all public-facing web services
Plain HTTP is prohibited for any endpoint that transmits or could expose user or student data. Internal service-to-service communication within production infrastructure must also use TLS.
4. Encryption at Rest
Student data and other sensitive organizational data must be encrypted at rest:
Data Category
Encryption Requirement
Student PII / education records
AES-256 or equivalent
Authentication credentials
Bcrypt, Argon2, or PBKDF2 (never plain or reversible)
API keys and secrets
Encrypted in secret management system (not in code)
Database storage
Database-level encryption enabled
File/media uploads
Storage-provider encryption at rest enabled
5. Key Management
•
Encryption keys must never be stored alongside the data they protect.
•
Application secrets and API keys are stored in a dedicated secret management service (e.g., Firebase Secret Manager, environment secrets).
•
Keys are rotated at least annually, and immediately upon suspected compromise.
•
Access to key management systems is restricted to the Security Lead and authorized engineers, and is logged.
•
Key rotation events are documented as audit evidence.
6. Prohibited Practices
The following are explicitly prohibited:
•
Use of MD5 or SHA-1 for any security-relevant purpose
•
Hardcoding encryption keys or secrets in source code or version control
•
Use of self-signed certificates in production environments
•
Rolling custom cryptographic algorithms or schemes
•
Disabling or downgrading TLS for convenience
7. Certificate Management
•
All production TLS certificates are tracked in a certificate inventory.
•
Expiration monitoring is automated; alerts are triggered at 30 days before expiry.
•
Expired certificates are treated as security incidents and remediated within 24 hours.
8. Review Cadence
This standard is reviewed annually or when a significant cryptographic vulnerability (e.g., protocol deprecation) is publicly disclosed.
9. Sign-Off
Security Lead: _________________________
Engineering Lead: _________________________
Date Approved: _________________________