You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tooling.apache.org by as...@apache.org on 2026/05/05 20:52:04 UTC
(tooling-agents) branch main updated: ASVS audit: 11.2.1.md (redacted) [source: apache/steve/v3 @ d0aa7e9]
This is an automated email from the ASF dual-hosted git repository.
asf-tooling pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tooling-agents.git
The following commit(s) were added to refs/heads/main by this push:
new 1184648 ASVS audit: 11.2.1.md (redacted) [source: apache/steve/v3 @ d0aa7e9]
1184648 is described below
commit 11846489b4a0233b11989b5759c46ca9b1ef5021
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Tue May 5 22:51:50 2026 +0200
ASVS audit: 11.2.1.md (redacted) [source: apache/steve/v3 @ d0aa7e9]
---
ASVS/reports/steve/v3/d0aa7e9/all/11.2.1.md | 149 ++++++++++++++++++++++++++++
1 file changed, 149 insertions(+)
diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/11.2.1.md b/ASVS/reports/steve/v3/d0aa7e9/all/11.2.1.md
new file mode 100644
index 0000000..654cb7a
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/11.2.1.md
@@ -0,0 +1,149 @@
+# Security Audit Report: ASVS 11.2.1
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 11.2.1 |
+| **Files Analyzed** | 8 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that industry-validated implementations (including libraries and hardware-accelerated implementations) are used for cryptographic operations.
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 0 |
+| 🟡 Medium | 1 |
+| 🟢 Low | 0 |
+
+---
+
+## ASVS-11.2.1: Industry-Validated Cryptographic Implementations
+
+### Findings for 11.2.1
+
+#### [MEDIUM]
+**Finding ID:** ASVS-1121-MED-001
+**Title:** Argon2d (Type.D) Used Instead of Recommended Argon2id (Type.ID)
+
+**Location:** `v3/steve/crypto.py`, line 89
+
+**Vulnerable code:**
+```python
+def _hash(data: bytes, salt: bytes) -> bytes:
+ "Use Argon2 to hash the data, with default tuning parameters."
+
+ return argon2.low_level.hash_secret_raw(
+ secret=data,
+ salt=salt,
+ time_cost=2, # Passlib default
+ memory_cost=65536, # Passlib default
+ parallelism=4, # Passlib default
+ hash_len=32, # Standard Argon2 digest length
+ type=argon2.low_level.Type.D, # <-- Side-channel vulnerable variant
+ )
+```
+
+**Context — Benchmark uses Type.ID:**
+```python
+def benchmark_argon2():
+ ...
+ argon2.low_level.hash_secret_raw(
+ ...
+ type=argon2.low_level.Type.ID, # <-- Recommended variant
+ )
+```
+
+**Description:**
+The production `_hash()` function uses Argon2d (data-dependent memory access), which is vulnerable to side-channel attacks (cache-timing attacks). RFC 9106 and OWASP recommend Argon2id for most applications, as it combines the side-channel resistance of Argon2i with the GPU/ASIC resistance of Argon2d.
+
+The benchmark function at line 118 correctly uses `Type.ID`, suggesting awareness of the recommended variant, but the production code was not updated.
+
+**Data flow:** `gen_opened_key()` → `_hash()` with Type.D; `gen_vote_token()` → `_hash()` with Type.D
+
+**Impact:** In environments where an attacker can observe memory access patterns (shared hosting, VMs, certain cloud environments), Argon2d is vulnerable to side-channel extraction of the secret. This could enable extraction of opened_keys or vote_tokens.
+
+**Remediation:**
+```python
+def _hash(data: bytes, salt: bytes) -> bytes:
+ "Use Argon2 to hash the data, with default tuning parameters."
+
+ return argon2.low_level.hash_secret_raw(
+ secret=data,
+ salt=salt,
+ time_cost=2,
+ memory_cost=65536,
+ parallelism=4,
+ hash_len=32,
+ type=argon2.low_level.Type.ID, # RFC 9106 recommended
+ )
+```
+
+### Security Controls Inventory for 11.2.1
+
+| Control | Library/Implementation | Version | Status |
+|---------|----------------------|---------|--------|
+| Symmetric encryption | `cryptography` (Fernet/AES-128-CBC) | >=46.0.5,<47 | ✓ Validated library |
+| Key derivation (HKDF) | `cryptography.hazmat.primitives.kdf.hkdf` | >=46.0.5,<47 | ✓ Validated library |
+| Password/key hashing | `argon2-cffi` (reference C impl) | >=25.1.0,<26 | ✓ Validated library, ⚠️ Wrong variant |
+| General hashing | `hashlib.blake2b` (Python stdlib) | Python >=3.10 | ✓ Validated |
+| Random generation | `secrets` module (Python stdlib) | Python >=3.10 | ✓ CSPRNG |
+| Dependency pinning | `pyproject.toml` | N/A | ✓ Versions constrained |
+
+### Positive Patterns for 11.2.1
+
+- All cryptographic operations use well-known, peer-reviewed libraries
+- Library versions are pinned in `pyproject.toml` with upper bounds (e.g., `cryptography>=46.0.5,<47`)
+- No custom/homebrew cryptographic primitives are implemented
+- The Fisher-Yates shuffle in `crypto.py` correctly uses `secrets.randbelow()` (CSPRNG) instead of `random`
+- Salt generation uses `secrets.token_bytes()` (CSPRNG)
+- ID generation uses `secrets.token_hex()` (CSPRNG)
+
+---
+
+
+
+## Cross-cutting Architecture Observations
+
+1. **Centralized Crypto Module:** All cryptographic operations are centralized in `v3/steve/crypto.py`. This is excellent for auditability but currently lacks the abstraction needed for agility. The centralization makes future refactoring feasible.
+
+2. **Key Derivation Chain:** The system uses a well-designed multi-level key derivation: `election_data → BLAKE2b → Argon2 → opened_key → (+ pid + iid + salt) → Argon2 → vote_token → HKDF → vote_key → Fernet(vote)`. This provides good key separation and limits blast radius, but the entire chain is hardcoded.
+
+3. **Documentation Gap:** The project has partial documentation (`schema.md`) but lacks formal security/crypto documentation. The existing documentation focuses on database schema rather than cryptographic design decisions.
+
+4. **Anti-Tamper Design:** The `opened_key` serves dual purposes: (1) tamper detection via `is_tampered()` and (2) vote token derivation. This coupling means the anti-tamper mechanism is tied to the same cryptographic algorithm as the voting mechanism — upgrading one requires upgrading both.
+
+5. **No Asymmetric Cryptography:** The system uses only symmetric primitives and key derivation. This reduces PQC urgency compared to systems using RSA/ECC, but the AES-128 effective key length under Grover's algorithm (64-bit) is a concern for long-term data confidentiality.
+
+6. **Inconsistency Between Production and Benchmark:** Production uses Argon2d while the benchmark uses Argon2id, suggesting either incomplete migration or a deliberate but undocumented choice.
+
+## Cross-cutting Recommendations
+
+### Immediate (Sprint-level)
+1. **Change Argon2d to Argon2id** in `_hash()` function (ASVS-1121-MED-001). This is a one-line change with significant security improvement. Note: this will change all derived values, so must be coordinated with any existing deployed databases.
+
+2. **Add `crypto_version` column** to the `vote` table to enable future algorithm transitions without data loss.
+
+### Short-term (1-3 months)
+3. **Create formal cryptographic inventory document** mapping all algorithms, keys, their purposes, access scopes, and protection requirements (satisfies 11.1.1, 11.1.2).
+
+4. **Implement crypto abstraction layer** in `crypto.py` with version-based algorithm selection and a configuration mechanism for algorithm parameters (satisfies 11.2.2).
+
+5. **Add cryptographic linting** to CI/CD pipeline using `semgrep` or equivalent with rules for:
+ - Flagging new crypto imports
+ - Detecting weak algorithms
+ - Ensuring CSPRNG usage (satisfies 11.1.3)
+
+### Long-term (3-12 months)
+6. **Complete Fernet → XChaCha20-Poly1305 migration** with proper versioning, re-encryption tooling, and rollback capability.
+
+7. **Document PQC migration plan** assessing quantum risk for each primitive and establishing upgrade timelines, particularly upgrading to AES-256 for long-term vote confidentiality (satisfies 11.1.4).
+
+8. **Implement key lifecycle management** including maximum key age, scheduled rotation for long-lived keys, and secure key destruction after election archival (satisfies 11.1.1).
+
\ No newline at end of file
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@tooling.apache.org
For additional commands, e-mail: commits-help@tooling.apache.org