1.0 Purpose

The Velentium Medical Cryptographic Assurance Levels (VEL-CAL) framework defines a tiered classification system for selecting cryptographic primitives and configurations in medical device systems. It is designed to ensure alignment with U.S. and international standards and regulations, enable scalable and risk-informed design decisions, and promote forward compatibility with post-quantum cryptography. The framework establishes three levels of cryptographic strength. Level 1 represents the minimum acceptable baseline for regulatory compliance and security. Levels 2 and 3 offer increasing protection aligned with risk severity, data sensitivity, device type, and anticipated lifecycle.

2.0 Cryptographic Strength by Primitive Type

The following content further elaborates on the CAL levels for the various cryptographic primitive types.

2.1 Symmetric Encryption

Symmetric encryption uses a single, shared secret key for both encryption and decryption operations. It is efficient and well-suited for protecting large volumes of data in resource-constrained environments or in scenarios where a third-party is not accessible for use in identity verification. Common symmetric encryption algorithms include AES (Advanced Encryption Standard) and ChaCha20.

2.1.1 Additional Symmetric Encryption Considerations

• Refer to Velentium Medical’s SEC-GUIDE-02 AES Symmetric Cryptography Guide for detailed implementation guidance and best practices.

• Modes of operation significantly affect security. Avoid ECB; use GCM or CTR for secure communications, and XTS or CBC for data storage.

• Initialization Vectors (IVs) must be unique, random, and never reused with the same key in modes like CBC, CTR, and GCM.

• Padding schemes (e.g., PKCS#7) are needed for block modes like CBC. - Prefer hardware-supported AES (e.g., AES-NI or microcontroller crypto engines) to reduce side-channel risk.

• Ascon-AEAD128, standardized by NIST in SP 800-232, is a lightweight authenticated encryption algorithm appropriate for resource-constrained medical devices requiring 128-bit security strength.

2.2 Asymmetric Encryption

Asymmetric encryption uses a pair of mathematically related keys where one key is used for encryption and a different key is used for decryption. It enables secure key exchange, digital signatures, and identity authentication, particularly in open and untrusted environments where internet connectivity is available. Common asymmetric encryption algorithms include RSA and Elliptic Curve Cryptography (ECC).

2.2.1 Additional Asymmetric Encryption Considerations

• ECC is generally preferred over RSA due to its shorter key sizes and improved performance for equivalent security.

• Asymmetric cryptography is resource-intensive; evaluate performance tradeoffs on constrained devices.

• Always validate public keys and enforce proper certificate chains or root-of-trust models.

• Use padding schemes like OAEP (for RSA encryption) or PSS (for RSA signatures) to mitigate padding oracle attacks.

• Consider hybrid modes (e.g., ECC + post-quantum cryptography KEM) for future-proof deployments.

• RSA is supported only for backward compatibility; new designs should prefer ECC or PQ hybrids.

2.3 Digital Signatures

Digital signatures provide cryptographic proof that a message or document was created by a known sender and has not been altered. They use asymmetric key algorithms and are critical for ensuring authenticity, integrity, and non-repudiation in medical device systems. Common schemes include RSASSA-PSS, ECDSA, and emerging post-quantum signature algorithms.

2.3.1 Additional Digital Signature Considerations

• Use RSASSA-PSS over PKCS1v1.5 for new implementations to improve resistance to signature forgery.

• Signatures must be verifiable across system lifecycle (consider impact of expired or revoked keys).

• Ensure all signed artifacts (firmware, logs, messages) include embedded metadata for validation

• Use time-stamping or signature counters to prevent replay or rollback attacks.

• Evaluate post-quantum safe signature schemes for long-lifecycle devices subject to future regulatory updates.

• RSASSA-PKCS1v1.5 is permitted only for verifying legacy signatures; new designs shall use RSASSA-PSS or ECDSA.

2.4 Hash Functions

Cryptographic hash functions generate a fixed-size output (hash) from input data, providing a fingerprint that is unique, deterministic, and infeasible to reverse. They are used for integrity checks, password hashing, and digital signatures. Common hash functions include SHA-256, SHA-3, BLAKE2, and BLAKE3.

2.4.1 Additional Hashing Considerations

• Refer to Velentium Medical’s SEC-GUIDE-01 Cryptographic Hashing Guide for in-depth guidance on cryptographic hash selection and implementation strategies.

• Cryptographic hash functions must be collision-resistant, non-reversible, and deterministic.

• Avoid legacy algorithms like MD5 and SHA-1. SHA-1 may only be used for verification of legacy signatures; it shall not be used for generating new digests.

• Use CMAC or HMAC for authentication where a secret key is involved.

• Ascon-Hash256 and Ascon-XOF128 are approved lightweight cryptographic primitives per NIST SP 800-232 and may be appropriate where SHA-based hashing is infeasible.

2.5 Key Agreement and Derivation

Key agreement and derivation schemes enable two or more parties to securely establish shared keys over potentially untrusted networks. These primitives underpin secure communications protocols and authentication frameworks. Common algorithms include ECDH (Elliptic Curve Diffie-Hellman) and HKDF (HMAC-based Extract-and-Expand Key Derivation Function).

An HKDF should be implemented using HMAC-SHA-2 or SHA-3, per NIST SP 800-56C. Ascon-XOF128/-CXOF128 may be used for KDF contexts in constrained devices where SHA-2/3 are infeasible.

2.6 Lightweight Cryptography for Constrained Devices

Medical devices often operate in environments with strict constraints on power, memory, and processing capacity. In such contexts, NIST SP 800-232 defines the Ascon family of lightweight cryptographic primitives for use in embedded and low-resource systems.

The Ascon suite includes:

• Ascon-AEAD128: Authenticated encryption with associated data (AEAD)

• Ascon-Hash256: Cryptographic hash function

• Ascon-XOF128 and Ascon-CXOF128: eXtendable Output Functions

These primitives provide 128-bit security strength and are designed for ease of implementation on microcontrollers. Ascon may be appropriate for Level 1 or Level 2 cryptographic applications when AES or SHA-based primitives are infeasible. Implementers should refer to NIST SP 800-232 for algorithm specifications and limitations. 

3.0 Use Case Mapping to Cryptographic Levels

The table below provides examples of use cases where various levels of cryptographic strength are recommended for encryption, integrity verification, authentication, and non-repudiation.

4.0 Algorithm Acceptance Matrix

The following algorithms are acceptable for use at Velentium Medical under the defined circumstances. For example, RSA and SHA-1 are only allowed for backwards compatibility and for legacy devices but are disallowed for new development at Velentium Medical.

5.0 Key Management Expectations

Managing security secrets, or in this case cryptographic keys, is one of the most difficult aspects of using cryptography for security purposes. The table below provides various suggestions for each level of cryptographic strength for generating, storing, rotating, and distributing keys used for cryptographic operations.

6.0 Standards and Regulatory Alignment

This framework aligns with the standards listed in the table below.

• NIST SP 800-57: Defines strength levels and key size equivalencies

• NIST SP 800-131A: Approves/disallows algorithms based on strength and lifecycle

• ISO/IEC 19790: Cryptographic module security (basis of FIPS 140-3)

• IEC 81001-5-1: Requires standards-based, vetted crypto for health software

• FDA Premarket Cybersecurity Guidance (2025): Calls for strong, standards-based crypto in design and updates

• NIST SP 800-232: Approves Ascon algorithms for lightweight cryptography in constrained devices (AEAD, hash, XOF)

7.0 Summary Statement

The Velentium Medical Cryptographic Assurance Levels (VEL-CAL) framework ensures that all cryptographic mechanisms used in medical device systems meet or exceed globally recognized standards. Level 1 establishes the regulatory baseline for acceptable strength, while Levels 2 and 3 support enhanced risk protection and post-quantum resilience.

Download the VEL-CAL Framework in PDF Format