Key Generation
Specification
Generate Cryptographic keys using industry accepted cryptographic libraries specifying the algorithm strength and the random number generator used.
Threat coverage
Architectural relevance
Lifecycle
Data storage
Not applicable
Not applicable
Orchestration, AI Services supply chain, AI applications
Maintenance, Continuous monitoring
Data deletion
Ownership / SSRM
PI
Shared Cloud Service Provider-Model Provider (Shared CSP-MP)
The CSP and MP are jointly responsible and accountable for the design, development, implementation, and enforcement of the control to mitigate security, privacy, or compliance risks associated with Large Language Model (LLM)/GenAI technologies in the context of the services or products they develop and offer.
Model
Owned by the Model Provider (MP)
The model provider (MP) designs, develops, and implements the control as part of their services or products to mitigate security, privacy, or compliance risks associated with the Large Language Model (LLM). Model Providers are entities that develop, train, and distribute foundational and fine-tuned AI models for various applications. They create the underlying AI capabilities that other actors build upon. Model Providers are responsible for model architecture, training methodologies, performance characteristics, and documentation of capabilities and limitations. They operate at the foundation layer of the AI stack and may provide direct API access to their models. Examples: OpenAI (GPT, DALL-E, Whisper), Anthropic(Claude), Google(Gemini), Meta(Llama), as well as any customized model.
Orchestrated
Shared Model Provider-Orchestrated Service Provider (Shared MP-OSP)
The MP and OSP are jointly responsible and accountable for the design, development, implementation, and enforcement of the control to mitigate security, privacy, or compliance risks associated with Large Language Model (LLM)/GenAI technologies in the context of the services or products they develop and offer.
Application
Owned by the Application Provider (AP)
The Application Provider (AP) is responsible for the design, development, implementation, and enforcement of the control to mitigate security, privacy, or compliance risks associated with Large Language Model (LLM)/GenAI technologies in the context of the services or products they develop and offer. The AP is responsible and accountable for the implementation of the control within its own infrastructure/environment. If the control has downstream implications on the users/customers, the AP is responsible for enabling the customer and/or upstream partner in the implementation/configuration of the control within their risk management approach. The AP is accountable for carrying out the due diligence on its upstream providers (e.g MPs, Orchestrated Services) to verify that they implement the control as it relates to the service/product develop and offered by the AP. These providers build and offer end-user applications that leverage generative AI models for specific tasks such as content creation, chatbots, code generation, and enterprise automation. These applications are often delivered as software-as-a-service (SaaS) solutions. These providers focus on user interfaces, application logic, domain-specific functionality, and overall user experience rather than underlying model development. Example: OpenAI (GPTs,Assistants), Zapier, CustomGPT, Microsoft Copilot (integrated into Office products), Jasper (AI-driven content generation), Notion AI (AI-enhanced productivity tools), Adobe Firefly (AI-generated media), and AI-powered customer service solutions like Amazon Rufus, as well as any organization that develops its AI-based application internally.
Implementation guidelines
Auditing guidelines
1. Verify that the CSP uses approved, standards-based cryptographic libraries (e.g., FIPS 140-2/3 certified) to generate encryption keys for cloud infrastructure services (e.g., storage, compute, networking) and tenant-facing key management systems. 2. Confirm that key generation processes specify algorithm type and strength (e.g., RSA-2048, AES-256), based on the classification of protected data and associated regulatory requirements. 3. Validate that cryptographic random number generators (RNGs) used for key generation comply with recognized standards (e.g., NIST SP 800-90A), and that entropy sources are appropriately managed across cloud regions. 4. Verify that key generation is automated and integrated into secure provisioning systems (e.g., KMS, HSM-backed infrastructure, service control planes), with strict identity and access controls. 5. Review permissions and audit configurations to ensure only authorized personnel, services, or tenants are allowed to initiate or request key generation. 6. Confirm that tenant-scope keys (e.g., BYOK, HYOK) and system-level keys (e.g., boot disk encryption, object store encryption) follow the same generation standards and are managed separately. 7. Verify that keys are not hardcoded, embedded in service templates, or stored in cloud automation scripts or manifests. 8. Review logging mechanisms that capture key generation events, including tenant identifier (if applicable), algorithm used, source system, timestamp, and outcome. 9. Confirm that keys used in development or test environments are generated separately using logically isolated and cryptographically distinct RNG instances from those in production. 10. Validate that CSP key generation procedures are reviewed periodically to reflect evolving cryptographic standards, multi-tenant service risks, and dependencies with upstream crypto modules and downstream customer-managed encryption features. From CCM: 1. Confirm that the organization has an approved process for the generation of cryptographic keys. 2. Identify the keys being used. 3. Observe the generation of an encryption key in a production-like sandbox or as a test tenant in production and confirm the keys have been generated according to the appropriate procedure and technical specifications.
Standards mappings
No Mapping for ISO 42001 ISO 27001: A.8.24 ISO 27002: 8.24
Addendum
ISO 42001 lacks this specific mandate for key generation practices in AI systems. Add a control requiring AI systems to generate cryptographic keys using industry-accepted cryptographic libraries, explicitly specifying algorithm strength and the random number generator used, addressing the gap in ISO 42001:2023’s lack of detailed key generation requirements. Include implementation guidance referencing standards (e.g., NIST SP 800-57), enhancing ISO 27001 (A.8.24) and ISO 27002 (8.24) for AI-specific cryptographic precision.
No Mapping
Addendum
Cover the AICM control.
No Mapping
Addendum
No (implicit/explicit) reference to cryptography, encryption, or key management is made in the NIST AI 600-1 standard, let alone to the requirement of generating cryptographic keys according to industry-accepted libraries.
CRY-02 CRY-03 CRY-04
Addendum
N/A
AI-CAIQ questions (1)
Are cryptographic keys generated using industry-accepted and approved cryptographic libraries that specify algorithm strength and random number generator specifications?