Cryptography Policy¶
| Owner | Classification | Review Date | Status |
|---|---|---|---|
| CDO Office | Internal | April 2027 | Active |
| Field | Details |
|---|---|
| Document Type | Policy |
| Document Reference | SP-CRY-008 |
| Version | 1.3 |
| Owner | CISO |
| Classification | Confidential |
| Review Cycle | Annual |
Introduction¶
Cryptographic controls are essential to protecting the confidentiality, integrity, and authenticity of Simpaisa's information assets. This policy defines the requirements for the selection, deployment, and management of cryptographic techniques and key management practices across Simpaisa's systems and services.
This policy applies to all systems, applications, and communications that process, transmit, or store sensitive or confidential information on behalf of Simpaisa.
Policy on the Use of Cryptographic Controls¶
Risk Assessment¶
The use of cryptographic controls shall be based on a risk assessment that considers:
-
The classification and sensitivity of the data being protected
-
The threat environment and likelihood of interception or unauthorised access
-
Applicable legal, regulatory, and contractual requirements for data protection
-
The potential business impact of data compromise
A risk assessment shall be conducted before selecting and deploying cryptographic controls for any new system or significant change to an existing system.
Technique Selection¶
Cryptographic techniques shall be selected based on the outcomes of the risk assessment, the sensitivity of the data, and current industry best practice. Simpaisa shall use only cryptographic algorithms and key lengths that are recognised as strong by relevant standards bodies (e.g., NIST, ECRYPT).
The following table defines the approved cryptographic techniques for use within Simpaisa's environment:
| Use Case | Approved Algorithm(s) | Minimum Key Length | Notes |
|---|---|---|---|
| Data encryption at rest | AES | 256-bit | AES-256-GCM preferred |
| Data encryption in transit | TLS | TLS 1.2 minimum; TLS 1.3 preferred | SSLv3, TLS 1.0, TLS 1.1 prohibited |
| Asymmetric encryption | RSA | 2048-bit minimum; 4096-bit recommended | ECC (P-256 or higher) also approved |
| Digital signatures | RSA, ECDSA | RSA 2048-bit; ECDSA P-256 minimum | Used for code signing, document signing |
| Hashing | SHA-2 family | SHA-256 minimum | SHA-1 and MD5 prohibited |
| Message authentication | HMAC | HMAC-SHA-256 minimum | — |
| Password hashing | bcrypt, Argon2, PBKDF2 | bcrypt cost factor ≥12; Argon2id recommended | Plain text and MD5 password storage prohibited |
| Email security | PGP | 2048-bit RSA or higher | Used for sensitive email communications |
| API authentication tokens | JWT (JSON Web Token) | RS256 or ES256 signing | HS256 prohibited in production |
| VPN / secure tunnels | IPsec, OpenVPN | AES-256 encryption; SHA-256 integrity | — |
Prohibited algorithms include: DES, 3DES, RC4, MD5 (for security purposes), SHA-1, SSLv3, TLS 1.0, TLS 1.1, and any algorithm with known significant vulnerabilities.
Deployment¶
Cryptographic controls shall be deployed in accordance with the following requirements:
-
Cryptographic implementations shall use vetted, well-maintained libraries and shall not rely on custom or home-grown cryptographic code
-
Default and example cryptographic configurations shall be reviewed and hardened before deployment to production
-
All cryptographic implementations shall be tested before deployment to confirm correct operation
-
Cryptographic controls shall be documented as part of the system's security architecture
Testing and Review¶
-
Cryptographic implementations shall be reviewed as part of security assessments and code reviews
-
Cryptographic standards shall be reviewed at least annually to ensure they remain current and effective
-
Any deprecated algorithm or configuration identified shall be remediated within a defined timeframe agreed with the CISO
Key Management¶
Cryptographic keys are critical security assets. Compromised or mismanaged keys can render cryptographic controls ineffective. Simpaisa shall implement robust key management practices to protect all cryptographic keys throughout their lifecycle.
Key Lifecycle Stages¶
Key management shall address the following lifecycle stages:
-
Generation — Keys shall be generated using cryptographically secure random number generators. Key generation shall occur in a secure environment.
-
Distribution — Keys shall be distributed securely using encrypted channels. Keys shall never be transmitted in plain text.
-
Storage — Keys shall be stored securely, separate from the data they protect. Keys shall be encrypted at rest using a master key or hardware security module (HSM) where available.
-
Use — Keys shall be used only for their intended purpose. Key usage shall be logged for audit purposes.
-
Rotation — Keys shall be rotated on a defined schedule or upon any suspected compromise. Rotation schedules shall be risk-based.
-
Revocation — Keys shall be immediately revoked upon suspected or confirmed compromise, or when no longer required.
-
Destruction — Keys that are no longer required shall be securely destroyed in a manner that prevents recovery.
Cryptographic Architecture¶
The following table defines the cryptographic architecture for Simpaisa's key systems:
| System / Use Case | Algorithm | Key Type | Key Length | Rotation Period | Storage |
|---|---|---|---|---|---|
| Email encryption (sensitive communications) | PGP | Asymmetric | 4096-bit RSA | Annual | Key server / secure vault |
| Data integrity verification | SHA-256 | Hash | N/A (256-bit output) | N/A | N/A |
| SSL/TLS certificates | RSA / ECDSA | Asymmetric | 2048-bit RSA / P-256 ECDSA | Annual (or on expiry) | Certificate store / secrets manager |
| API authentication (JWT signing) | RS256 (RSA) | Asymmetric | 2048-bit RSA | 90 days | Secrets manager |
| Database encryption | AES-256 | Symmetric | 256-bit | Annual | HSM / secrets manager |
| Backup encryption | AES-256 | Symmetric | 256-bit | Annual | HSM / secrets manager |
| Code signing | RSA / ECDSA | Asymmetric | 2048-bit RSA / P-256 ECDSA | Annual | Code signing certificate store |
All key management activities shall be documented and subject to audit. Access to cryptographic keys shall be restricted to authorised personnel on a need-to-know basis and shall be logged.