1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

// Secure Key Generation - Best Practices
 
// ✅ CORRECT: Use OS-provided CSPRNG
import { randomBytes } from 'crypto';
 
function generateAES256Key(): Buffer {
    // crypto.randomBytes uses OS entropy pool
    // On Linux: /dev/urandom
    // On Windows: CryptGenRandom  
    // On modern systems: Hardware RNG when available
    return randomBytes(32);  // 256 bits
}
 
// ✅ CORRECT: Generate key for IKE pre-shared key
function generatePSK(lengthBytes: number = 32): string {
    const bytes = randomBytes(lengthBytes);
    // Base64 encode for configuration file storage
    return bytes.toString('base64');
}
 
// ❌ WRONG: Using predictable sources
function INSECURE_generateKey(): Buffer {
    // Math.random() is NOT cryptographically secure!
    const key = Buffer.alloc(32);
    for (let i = 0; i < 32; i++) {
        key[i] = Math.floor(Math.random() * 256);
    }
    return key;
}
 
// ❌ WRONG: Insufficient entropy
function INSECURE_keyFromPassword(password: string): Buffer {
    // Simple hash of password has limited entropy
    // If password is "Password123", key space is tiny
    return crypto.createHash('sha256').update(password).digest();
}
 
// ✅ CORRECT: Password-based key derivation with proper KDF
async function deriveKeyFromPassword(
    password: string,
    salt: Buffer,
    iterations: number = 100000
): Promise<Buffer> {
    // PBKDF2/Argon2 stretches limited password entropy
    return new Promise((resolve, reject) => {
        crypto.pbkdf2(password, salt, iterations, 32, 'sha256', (err, key) => {
            if (err) reject(err);
            else resolve(key);
        });
    });
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

// Diffie-Hellman Key Exchange (Conceptual)
 
// Public parameters (known to everyone, including attackers):
// g = generator
// p = large prime (or elliptic curve parameters)
 
// Initiator:
i_private = random()                    // Private: never leaves initiator
i_public = g^i_private mod p           // Public: sent to responder
 
// Responder:
r_private = random()                    // Private: never leaves responder
r_public = g^r_private mod p           // Public: sent to initiator
 
// Shared secret computation:
// Initiator computes: shared = (r_public)^i_private mod p
//                           = (g^r_private)^i_private mod p
//                           = g^(r_private * i_private) mod p
 
// Responder computes: shared = (i_public)^r_private mod p
//                           = (g^i_private)^r_private mod p
//                           = g^(i_private * r_private) mod p
 
// Both arrive at the same shared secret!
// Attacker observes: g, p, i_public, r_public
// To compute shared secret, attacker needs i_private or r_private
// This requires solving discrete logarithm - computationally infeasible
 
// IKE DH Groups (key sizes):
// Group 14: 2048-bit MODP  (minimum recommended)
// Group 19: 256-bit ECP    (NIST P-256 elliptic curve)
// Group 20: 384-bit ECP    (NIST P-384 elliptic curve)
// Group 21: 521-bit ECP    (NIST P-521 elliptic curve)
// Group 31: Curve25519     (modern, efficient)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

// Key Storage Patterns
 
// ❌ NEVER: Plaintext in configuration
ipsec_config = {
    psk: "SuperSecretKey123!",  // Visible to anyone with file access
}
 
// ⚠️ BETTER: Environment variable (still visible in process list)
const psk = process.env.IPSEC_PSK;
 
// ✅ GOOD: Encrypted configuration with secure master key
const config = loadEncryptedConfig(masterKeyFromHSM);
const psk = config.decrypt('ipsec_psk');
 
// ✅ BETTER: Key Management Service integration
const kms = new KeyManagementClient();
const psk = await kms.getSecret('ipsec/production/psk', {
    auditContext: { requestor: 'vpn-gateway-01' }
});
 
// ✅ BEST: HSM-based keys (key never leaves HSM)
const hsm = new HSMClient();
// Key is REFERENCED, not retrieved
const keyHandle = await hsm.getKeyHandle('ipsec-sa-key-001');
// Cryptographic operations happen ON the HSM
const encrypted = await hsm.encrypt(keyHandle, plaintext);
 
// Memory Protection During Use:
// - Minimize time keys are in memory
// - Use secure memory (mlock, no swap)
// - Zero memory after use
function secureCleanup(keyBuffer: Buffer): void {
    // Overwrite with zeros before release
    keyBuffer.fill(0);
    // Some systems support explicit secure free
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

// Key Rotation Best Practices
 
// SA Lifetime Configuration Example (StrongSwan)
connections {
    site-to-site {
        // Child SA (IPSec) lifetimes
        children {
            tunnel {
                // Rotate after 1 hour OR 1GB of traffic
                life_time = 1h
                life_bytes = 1g
                
                // Start rekeying at 90% of lifetime
                rekey_time = 54m      // 0.9 * 60 = 54
                rekey_bytes = 900m    // 0.9 * 1000 = 900
                
                // Hard limit (delete if not rekeyed by then)
                over_time = 10m       // Extra 10 minutes allowed
            }
        }
        
        // IKE SA lifetime
        rekey_time = 4h           // Rekey IKE SA every 4 hours
        over_time = 30m           // Grace period
    }
}
 
// Operational Key Rotation Checklist:
// 1. Monitor SA lifetimes and rekey success rates
// 2. Alert on rekey failures (indicates peer issues)
// 3. Ensure time synchronization (lifetime mismatches cause issues)
// 4. Test rotation under load (traffic continuity)
// 5. Log all rotations for audit trail
 
// PSK Rotation Procedure (Manual):
// 1. Generate new PSK: openssl rand -base64 48
// 2. Document and secure the new PSK
// 3. Schedule maintenance window
// 4. Update both endpoints simultaneously
// 5. Verify new IKE SA establishes correctly
// 6. Revoke access to old PSK
// 7. Update any backups/documentation

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

// Secure Key Destruction in Code
 
// ✅ CORRECT: Zero memory before release
function destroyKey(keyBuffer: Buffer): void {
    // Fill with zeros
    keyBuffer.fill(0);
    
    // Some languages/runtimes support explicit secure free
    // Node.js: Buffer is garbage collected, but zeroing prevents copies
    
    // In C: use explicit_bzero() or SecureZeroMemory()
    // These prevent optimizer from removing "dead" stores
}
 
// ✅ CORRECT: Crypto library cleanup
import { webcrypto } from 'crypto';
 
async function useAndDestroyKey() {
    const key = await webcrypto.subtle.generateKey(
        { name: 'AES-GCM', length: 256 },
        true,  // extractable for destruction
        ['encrypt', 'decrypt']
    );
    
    try {
        // Use the key
        await encrypt(key, data);
    } finally {
        // Some implementations don't expose explicit destruction
        // Best practice: use non-extractable keys when possible
        // Key material stays in secure enclave
    }
}
 
// ⚠️ Be aware of copies:
function AVOID_thisCopiesKey(key: Buffer): void {
    const keyString = key.toString('hex');  // Creates a copy!
    console.log('Key hash:', hash(keyString));  // String persists
    key.fill(0);  // Original zeroed, but keyString still exists!
}
 
// SA Deletion in IPSec:
// When SA is deleted:
// 1. Remove from SAD (reference deleted)
// 2. Zero all key material in SA structure
// 3. Free memory
// 4. Send DELETE notification to peer
// 5. Peer performs same cleanup