Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Understanding CAN/CSA-ISO/IEC 17960-16: Code Signing for Software and Firmware Security
A comprehensive guide to the requirements and implementation of code signing as per the Canadian adoption of ISO/IEC 17960
In an era where software and firmware are integral to critical infrastructure, industrial control systems, and everyday devices, ensuring the authenticity and integrity of code is paramount. The standard CAN/CSA-ISO/IEC 17960-16—the Canadian adoption of ISO/IEC 17960:2015—provides a robust framework for code signing systems. This article details the scope, technical requirements, implementation considerations, and compliance aspects of this international standard.
Scope and Purpose of CAN/CSA-ISO/IEC 17960-16
CAN/CSA-ISO/IEC 17960-16 defines the requirements for code signing, a security technique that applies digital signatures to software and firmware. The standard covers three key roles:
- Signers – entities that generate signatures.
- Verifiers – processes that validate signatures before installation or execution.
- Trust Anchors – authorities that issue and manage signing certificates.
The primary goal is to protect against unauthorized code modifications, verify the identity of the publisher, and ensure that only trusted code runs in a target environment. The standard applies to operating systems, mobile platforms, embedded systems, firmware updates, and applications distributed via app stores.
Key Benefit: Adopting CAN/CSA-ISO/IEC 17960-16 helps organizations build user trust, satisfy regulatory requirements, and reduce the attack surface related to malicious code injection.
Technical Requirements for Code Signing Systems
The standard specifies a set of technical controls for signature generation, verification, key management, and certificate handling.
Digital Signatures and Algorithms
Signatures must be created using cryptographically strong algorithms. The standard references well-established schemes such as RSA and ECDSA with appropriate hash functions. The table below lists accepted algorithm combinations:
| Algorithm | Key Size (bits) | Hash Function | Status |
|---|---|---|---|
| RSA | 2048 | SHA-256 | ▶ Recommended |
| RSA | 4096 | SHA-384 / SHA-512 | ↔ Permitted |
| ECDSA | 256 (prime192) | SHA-256 | ▶ Recommended |
| ECDSA | 384 (prime384) | SHA-384 | ↔ Permitted |
| DSA | 2048 | SHA-256 | ⚠ Deprecated |
Certificate and Key Management
Every signer must possess a unique X.509v3 certificate issued by a recognized Certificate Authority (CA). The standard mandates:
- Use of enhanced key usage extension (EKU) for code signing (OID 1.3.6.1.5.5.7.3.3).
- Certificate path validation in accordance with RFC 5280.
- Key lifecycle management: secure generation, storage, backup, revocation, and destruction.
- Revocation checking via CRLs or OCSP before signature verification.
Implementation Tip: Always protect private signing keys in a Hardware Security Module (HSM) or a Trusted Platform Module (TPM) to meet the standard’s security requirements for non-exportable keys.
Implementation Highlights for Developers and Vendors
Deploying a code signing infrastructure requires careful integration into the software development lifecycle. Key aspects include:
Signing Process Integration
- Automate signing as the final step in the build pipeline.
- Apply timestamping (using an RFC 3161 Time-Stamp Authority) so signatures remain valid after certificate expiry.
- Sign all distributable artifacts: executables, libraries, installers, firmware images, and scripts.
Verification on Target
- The runtime environment must validate the signature before executing any code.
- Enforce certificate chain validation and key usage constraints.
- Fail securely—do not run code if signature verification fails.
Caution: Do not embed the private key in the source repository or CI/CD configuration. This violates the standard’s non-repudiation requirements and exposes the signing credential to theft.
Compliance and Auditing Considerations
Organizations pursuing conformance with CAN/CSA-ISO/IEC 17960-16 should prepare for assessments that examine:
- Security Policy: Documented code signing policy defining roles, key protection, and incident response.
- Key Protection: Use of FIPS 140-2/3 validated HSMs or equivalent secure storage for private keys.
- Audit Logs: Complete records of all signing operations, including signer identity, timestamp, artifact hash, and certificate details.
- Revocation Handling: Mechanism to detect revoked certificates and prevent signing with compromised keys.
Risk of Non-Compliance: Failure to implement the controls in CAN/CSA-ISO/IEC 17960-16 can lead to signed code being tampered with, distribution of malware under a trusted identity, and significant liability under cybersecurity regulations.
Adopting this standard demonstrates due diligence in cybersecurity and is often a prerequisite for government, defense, and critical infrastructure projects in Canada and internationally.
Frequently Asked Questions (FAQ)
Q: What is the relationship between CAN/CSA-ISO/IEC 17960-16 and the newer ISO/IEC 17960:2023?
A: CAN/CSA-ISO/IEC 17960-16 is the Canadian adoption of the 2015 edition. The 2023 version updates algorithm strengths and provides clearer guidance on quantum-safe signatures. Users are encouraged to evaluate the latest edition for new implementations.
A: CAN/CSA-ISO/IEC 17960-16 is the Canadian adoption of the 2015 edition. The 2023 version updates algorithm strengths and provides clearer guidance on quantum-safe signatures. Users are encouraged to evaluate the latest edition for new implementations.
Q: Does the standard require timestamping for every signature?
A: The standard recommends including a reliable timestamp (e.g., RFC 3161) to validate signatures beyond the signer’s certificate validity period. Most compliance regimes treat timestamping as a mandatory requirement for long-lived artifacts.
A: The standard recommends including a reliable timestamp (e.g., RFC 3161) to validate signatures beyond the signer’s certificate validity period. Most compliance regimes treat timestamping as a mandatory requirement for long-lived artifacts.
Q: Can small developers implement this standard without an HSM?
A: While the standard allows alternative key protection mechanisms (e.g., encrypted key files protected by strong passwords), using an HSM is strongly advised for higher assurance. Cloud-based key management services (like AWS KMS or Azure Key Vault) can also meet the security requirements when properly configured.
A: While the standard allows alternative key protection mechanisms (e.g., encrypted key files protected by strong passwords), using an HSM is strongly advised for higher assurance. Cloud-based key management services (like AWS KMS or Azure Key Vault) can also meet the security requirements when properly configured.
Article published: 2026