Geotab Cryptographic Module

Certificate

Approved Algorithms (5)

Derived Review-Risk Graph (review prompts, not findings)

flowchart LR
  %% Deterministic review-risk graph for Geotab Cryptographic Module
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>Update<br/>firmware load</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Status Output<br/>self-test<br/>Show status</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E2["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C6 --> I6 --> R6 --> E6
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C2,C3,C6 clue;
  class I2,I3,I6 infer;
  class R2,R3,R6 risk;
  class E2,E3,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Geotab Cryptographic Module
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>Update<br/>firmware load</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Status Output<br/>self-test<br/>Show status</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>application</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C2,C3,C6 clueLow;

Security Policy, page by page

Geotab Cryptographic Module FIPS 140-3 Non-Proprietary Security Policy Firmware Version 1.0 Document Version 1.0 ® denotes a trademark of Geotab Inc., which may be registered in certain countries This document may freely be reproduced and distributed in its entirety.

12. Mitigation of Other Attacks                                                       26 List of Tables Table 1: Security Levels                                                                  4 Table 2: Tested Operational Environments                                                  6 Table 3: Approved Algorithms                                                              7 Table 4: Ports and Interfaces                                                         10 Table 5: Roles, Service Commands, Input and Output                                    11 Table 6: Approved Services                                                            12 Table 7: SSPs                                                                         17 Table 8: Non-Deterministic Random Number Generation Specification                     18 Table 9: Pre-Operational Self Tests                                                   18 Table 10: Conditional Cryptographic Algorithm Tests                                   19 Table 11: Compilers                                                                   21 Table 12: Linkers                                                                     21 List of Figures Figure 1: Cryptographic Boundary                                                          8 Figure 2: TOEPP                                                                           9 Figure 3: Finite State Model                                                          23 Figure 4: State Transition Table                                                      25 ® denotes a trademark of Geotab Inc., which may be registered in certain countries This document may freely be reproduced and distributed in its entirety.

The following table lists the level of validation for each area in FIPS-140-3. Table 1: Security Levels ISO/IEC 24759 Section 6. FIPS-140-3 Section Title Security Level [Number Below]

2                        Cryptographic module                           1
3                        Cryptographic module interfaces                1
5                        Software/Firmware security                     1
6                        Operational environment                        1
7                        Physical security                              1
8                        Non-invasive security                         N/A
9                        Sensitive security parameter                   1
11                       Life-cycle assurance                           1
12                       Mitigation of other attacks                   N/A

® denotes a trademark of Geotab Inc., which may be registered in certain countries This document may freely be reproduced and distributed in its entirety.

® denotes a trademark of Geotab Inc., which may be registered in certain countries This document may freely be reproduced and distributed in its entirety.

2. Cryptographic Module Specification Module Description The Geotab Cryptographic Module, hereafter referred to as the module, is classified as Level 1 Firmware Module as per FIPS-140-3 guidelines operating within a limited operational environment. The module operates with a single-chip standalone module embodiment. The cryptographic boundary is a single-chip microcontroller which runs a limited operating environment such as bare-metal firmware image. The module is bundled with the firmware image used by the physical microcontrollers. The module performs no communication other than with the calling application via well-defined APIs that invoke the Module. Tested Configurations The product has been tested and is intended to operate on the following Geotab Operating Environments. There are no Vendor affirmed operational environments. Table 2: Tested Operational Environments

1                         N/A                        NXP S32K148              ARM CORTEX      N/A
2                         N/A                        ST STM32H7               ARM CORTEX M7   N/A

Approved Mode of Operation When properly initialized as specified in Section 11 of this document, the module only operates in an approved mode of operation. ® denotes a trademark of Geotab Inc., which may be registered in certain countries This document may freely be reproduced and distributed in its entirety.

Approved Algorithms Table 3: Approved Algorithms 800-90Ar1) with no PR Generation This module is compliant to IG C.F: The module utilizes the approved modulus size 2048 bits for RSA signatures. This functionality has been CAVP tested as noted above. RSA SigVer is CAVP tested for the supported modulus size as noted above. The module does not perform FIPS 186-2 SigVer. All supported modulus sizes are CAVP testable and tested as noted above. The module does not support “Vendor Affirmed Approved Algorithms”. Non-Approved Security Functions The module does not support any of the following: "Non-Approved Algorithms Allowed in the Approved Mode of Operation", "Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed", "Non-Approved Algorithms Not Allowed in the Approved Mode of Operation". ® denotes a trademark of Geotab Inc., which may be registered in certain countries This document may freely be reproduced and distributed in its entirety.

Module Boundary The following block diagram details modules' Cryptographic Boundary. The Tested Operational Environment's Physical Perimeter (TOEPP) is the physical perimeter of the Microcontroller/Special Purpose Computer. Cryptographic Boundary Figure 1: Cryptographic Boundary ® denotes a trademark of Geotab Inc., which may be registered in certain countries This document may freely be reproduced and distributed in its entirety.

TOEPP Figure 2: TOEPP ® denotes a trademark of Geotab Inc., which may be registered in certain countries This document may freely be reproduced and distributed in its entirety.

3. Cryptographic Module Interfaces The physical ports of the module are the same as the special purpose single chip microcontroller system on which it is executing. The logical interface is an application programming interface ( API ), the mapping of logical interface type is explained below. Table 4: Ports and Interfaces Physical Port Logical Interface Data that passes over N/A Data Input API entry point data input N/A Data Output API entry point data output N/A Control Input API entry point and corresponding parameters N/A Status Output API entry point return values Since the module is a firmware module, control of the physical ports is outside the module scope. When the module is in self-test state or error state, all output on the logical data output interface is prohibited. In the error state the module will only return an error value ( no data output is returned ). ® denotes a trademark of Geotab Inc., which may be registered in certain countries This document may freely be reproduced and distributed in its entirety.

4. Roles, Services and Authentication Roles The module supports following roles:

• User role: performs cryptographic services, gets module status.
• Crypto officer role: Performs module initialization ONLY. The module does not support operator authentication and does not allow concurrent operators. The user and Crypto Officer roles are implicitly assumed by the application accessing services implemented by the module. Table 5: Roles, Service Commands, Input and Output Crypto officer gc_Init Module HMAC Init status hash, signed hash ® denotes a trademark of Geotab Inc., which may be registered in certain countries This document may freely be reproduced and distributed in its entirety.

User gc_drbg_GetNextRandom Requested number of bytes DRBG output y Approved Services Access rights column key: G = Generate: The module generates or derives the SSP. R = Read: The SSP is read from the module (e.g. the SSP is output). W = Write: The SSP is updated, imported, or written to the module. X = Execute: The module uses the SSP in performing a cryptographic operation. Z = Zeroise: The module zeroises the SSP. Table 6: Approved Services instance and verify its integrity. Run 256 officer Completion of Pre-operational self tests. Proceed Service into operational state if initiation is successful or into error state if it is not. This is typically run on the power-on of the module t provided plaintext key Completion of pt provided plaintext key Completion of ® denotes a trademark of Geotab Inc., which may be registered in certain countries This document may freely be reproduced and distributed in its entirety.

y                     AES context. This also resets both                     key                       Completion of Encryption            in the specified AES context                                                     completion of service Decryption            in the specified AES context                                                     completion of service specified SHA context                                                            completion of service calculation for the specified context                                            completion of service provide the calculated hash                                                      completion of service Completion of gc_rsa_IsSignatur     Using the provided modulus and           RSA SigVer    RSA          User   WX    Successful eValid                exponent (public key), verify if the                   2048                      Completion of signed has was signed with the                         signature                 Service matching private key                                   verificati on key specified HMAC context                  56             Key                       Completion of calculation for the specified context   56             Key                       Completion of provide the calculated hash             56             Key                       Completion of gc_drbg_Init          Initialize the DRBG context and use     HMAC DRBG      DRBG         User   WX    Successful the module defined entropy function                    seed,                     Completion of to retrieve entropy for both entropy                   DRBG                      Service ® denotes a trademark of Geotab Inc., which may be registered in certain countries This document may freely be reproduced and distributed in its entirety.

and provide it with its entropy                        seed,                   Completion of acquisition function. This is only                     DRBG                    Service used for CAVP testing of DRBG.                         Entropy gc_drbg_GetNextR      Use DRBG to derive the required         HMAC DRBG      DRBG       User   X     Successful andom                 number of bytes                                        seed,                   Completion of gc_AddRawEntrop       Add raw entropy bytes to be             N/A            N/A        User   N/A   Successful of service gc_IsConditionedE     Indicates whether a sufficient          N/A            N/A        User   N/A   Successful ntropyReady           number of raw entropy bytes has                                                Completion of been added and processed by the                                                Service module to begin performing RBG gc_GetModuleStat      Indicates what state the module is      N/A            N/A        User   N/A   Successful e                     in. (Init, Error or Operational)                                               Completion of gc_GetModuleVer       Indicates what the current module       N/A            N/A        User   N/A   Successful sion                  version is                                                                     Completion of Power Cycle           Cuts power to the device and            N/A            All SSPs   User   Z     Successful zeroizes all SSPs stored in volatile                                           completion The indicator field of the above table specification of “successful completion of service” means services return success status; non-zero value or the approved security function finishes successfully. The module implements services corresponding to all mandatory services from FIPS 140-3, AS04.12 as denoted below: ® denotes a trademark of Geotab Inc., which may be registered in certain countries This document may freely be reproduced and distributed in its entirety.

● Show module’s versioning information - gc_GetModuleVersion ● Show status - gc_GetModuleState ● Perform self-tests - gc_Init ● Perform zeroisation - Power Cycle ● Perform approved security functions - All other services. Non-Approved Services The module does not support any non-approved services.

5. Software/Firmware Security The firmware module is in the form of a compiled binary, one for each supported operating environment. The module is closed source and does not require compilation by the user. After a module is powered on, the module’s integrity check is performed during module instantiation. The operator is able to initiate the integrity test on demand by re-initializing the module. Upon initialization the module performs an integrity test of the module on itself using HMAC-SHA2-256( Cert Num A4203). If the Integrity check fails, it will cause the module to enter the error state. Additionally the module performs listed self-tests (Specified in Section 10) and if successful the module will enter the Operational State.
6. Operational Environment The Module tested operating environments are listed below. The module implements a limited operating environment. The module functions entirely within the Operating environment provided space for the calling application. ● NXP S32K148 with S32K14X series processor ● ST STM32H7 with the STM32 Series Processor ® denotes a trademark of Geotab Inc., which may be registered in certain countries This document may freely be reproduced and distributed in its entirety.

System Description The system described by this security policy is a single-chip firmware module, running in a limited operational environment which loads a single binary, consisting of both the calling application and the validated module, that requires a power-on reset to install. The operating environment does not have an operating system and contains a single CPU with one core. The environment is single threaded and parallel execution is not possible. Program instructions of the module and volatile SSPs are stored within the cryptographic boundary. The module does not provide non-volatile key storage. Keys are provided externally by the application layer and are not stored by the module in non-volatile memory.

7. Physical Security The module is a single-chip cryptographic module and composed of production grade components. The module obtains its physical security from a single chip with standard passivation coating which protects against any environmental or physical damage. As the module consists of production grade components with standard passivation it satisfies the security requirements of Security Level 1.
8. Non-Invasive Security This cryptographic module does not claim any Non-Invasive security features.
9. Sensitive Security Parameters Management Sensitive Security Parameters The module does not persistently store any sensitive parameters within the module logical object. The module receives the SSPs through API calls to the module. The SSPs are not manually entered into or output from a module. All non-DRBG related sensitive security parameters are provided externally to the module and handled by the application using the module. The module supports the following SSP’s listed below. ® denotes a trademark of Geotab Inc., which may be registered in certain countries This document may freely be reproduced and distributed in its entirety.

Table 7: SSPs Entropy DRBG ed from Memory cycle an input ® denotes a trademark of Geotab Inc., which may be registered in certain countries This document may freely be reproduced and distributed in its entirety.

RBG Entropy Sources The entropy source resides outside the module's logical object but within the module’s physical perimeter. Table 8: Non-Deterministic Random Number Generation Specification Entropy sources Minimum number of bits of Details Accelerometer Based Entropy The entropy input string is 512 Produces 256-bits of entropy per Source bits, and the entropy source 256-bit output, and the DRBG produces full entropy. Minimum requests 512 bits from the number of bits of entropy should entropy source. be 512 bits. (Refer to ESV Cert #E86) SSP Zeroisation All SSP values are stored in volatile memory and are zeroized. The zeroization service for the SSP values consists of powering off the module, which resets the state of volatile memory and effectively sets all instances of SSPs to 0 values, making them non-retrievable. 10. Self-Tests A power cycle is required in order to run power on self-tests on demand. Pre-Operational Self-Tests Table 9: Pre-Operational Self Tests Pre-operational firmware integrity Integrity test performed on the module image. Integrity verified The Cryptographic algorithm test used to perform the approved integrity technique i.e. HMAC-SHA2-256 is passed before the Pre-operational software/firmware integrity test starts. The module does not support bypass. The module does not implement any pre-operational critical function tests. ® denotes a trademark of Geotab Inc., which may be registered in certain countries This document may freely be reproduced and distributed in its entirety.

Conditional Self Tests Conditional Cryptographic Algorithm Tests Table 10: Conditional Cryptographic Algorithm Tests AES-CBC-256 Encryption KAT Known answer test for AES-CBC-256, confirms that a known plaintext encrypts to a known ciphertext. AES-CBC-256 Decryption KAT Known answer test for AES-CBC-256, confirms that a known ciphertext decrypts to a known plaintext RSA-2048-Verify PKCS #1 v1.5 Known answer test for RSA-2048 confirms that a known signed SHA2-256 KAT message is successfully verified by a known key DRBG HMAC-SHA2-256 with no PR Known answer test for DRBG confirms that a known seed & input KAT (Instantiate & Generate) string input generates the expected entropy value HMAC-SHA2-256 KAT Known answer test for HMAC confirms that a Known key and message produce a known digest SP 800-90B RCT Health Test Continuous test performed whenever a new seed is requested by the DRBG from the conditioned entropy source (ESV#E86). confirms that the conditioned entropy source is not stuck. SP 800-90B APT Health Test Continuous test performed whenever a new seed is requested by the DRBG from the conditioned entropy source (ESV#E86). Confirms no loss of entropy occurs as a result of some physical failure or environmental change affecting the noise source. DRBG Continuous test Continuous test performed whenever a new random value is requested from DRBG. Confirms that the DRBG output is not stuck. DRBG Test Instantiate Known answer test to confirm that the instantiation completes as expected. The known answer is compared against the Generate output which is always called after. DRBG Test Generate Known answer test to confirm that generation completes as DRBG Test Un-instantiate Health Test to ensure that error handling is performed correctly, and the internal state has been zeroized The DRBG reseed function is unavailable as the module is never re-seeded during a power-on cycle. ® denotes a trademark of Geotab Inc., which may be registered in certain countries This document may freely be reproduced and distributed in its entirety.

Conditional Pair-Wise Consistency Test

• N/A Public/Private keys are not generated. Conditional software/firmware load test
• N/A. The module does not support a firmware load service. Conditional manual entry test
• N/A. No manual entry of SSP’s or key components. Conditional bypass test
• N/A. No Bypass Capability. Conditional critical functions test
• N/A. Error State If any self-test fails, the module enters the error state. In the error state, only the gc_GetModuleState and gc_GetModuleVersion API’s are available. All other API’s will return ‘1’ to indicate the error state. To attempt to clear the error, power off the module then power on and attempt to initialize the module again. ® denotes a trademark of Geotab Inc., which may be registered in certain countries This document may freely be reproduced and distributed in its entirety.

11. Life-Cycle Assurance Configuration Management The code repositories are managed through git based configuration management and version control systems. Table 11: Compilers Table 12: Linkers Vendor Testing The cryptographic module undergoes continuous unit tests and integration tests during the life-time of the module. On top of this, the cryptographic module undergoes continuous scanning through automatic diagnostic tools. Next section details automatic diagnostic tools in detail: ® denotes a trademark of Geotab Inc., which may be registered in certain countries This document may freely be reproduced and distributed in its entirety.

Security Tools Cryptographic modules are scanned for vulnerabilities using automatic diagnostic tools. Some of the rules enabled in this process are;

• Tainted array index detection
• Buffer overflow detection
• Integer overflow/underflow
• Command injection scanning
• Environment injection
• File injection Through this Cryptographic module development provides necessary assurance for secure code development and deployment. Delivery & Operation Initialization procedure shall be invoked as per to section Crypto Officer Services presented in this document. Crypto Officer has responsibility to ensure that all conditions of initialization are passed as recommended before the actual usage of the module begins. End of Life The module’s life is defined by the application invoking the APIs associated with the module. The module end of life is reached once the application relieves the module. The module does not persistently store any SSPs nor does it store information on non reconfigurable memory. The procedure for secure sanitization of the module is to power it off, which is the action of zeroization of the SSPs. The sanitization via power-off, results in removal of SSPs from the module. ® denotes a trademark of Geotab Inc., which may be registered in certain countries This document may freely be reproduced and distributed in its entirety.

Finite State Model Figure 3: Finite State Model States which are dotted are not present in the state machine. ® denotes a trademark of Geotab Inc., which may be registered in certain countries This document may freely be reproduced and distributed in its entirety.

The Finite State Model consists of following states:

• Power Off : The module embodiment (hardware) is powered off.
• Power On: The module embodiment (hardware) is powered on.
• Initialization: Module is initialized by calling Init routine.
• Integrity Check : the module checksum itself and verifies that it hasn’t been maliciously altered.
• Self Test : The module performs its KAT tests.
• Operational: Module is in its normal operating state, All APIs (gc_*) can be used at this moment and selected continuous testing is in force.
• Continuous Test: After the module is in the operational state, selected continuous testing is performed, and if returns error goes to error state otherwise back to operational state.
• Error: The module has entered error state, All APIs except gc_GetModuleState and gc_GetModuleVersion will return an error when used. Transition Initial State Resulting State Description

1                 Power Off                   Power On                    The module embodiment (hardware) is
2                 Power On                    Initialization              The module embodiment (hardware) is
3                 Initialization              Integrity Check             Module is initialized by calling init routine.
4                 Integrity Check             Self Test                   The module performs its KAT tests.
5                 Self Test                   Operational                 Module is in its normal operating state.
6                 Operational                 Continuous Test             After the module is in operational state,

selected continuous testing is performed, and if returns error, goes to error state, otherwise back to operational state.

7 Continuous Test Operational After the module is in the operational state,

selected continuous testing is performed, and if returns error, goes to error state otherwise back to operational state.

8 Integrity Check / Error The module has entered error state. All APIs

Self Test / except gc_GetModuleState and ® denotes a trademark of Geotab Inc., which may be registered in certain countries This document may freely be reproduced and distributed in its entirety.

Continuous Test gc_GetModuleVersion will return an error (‘1’) when used.

9 Operational / Error Power Off The module embodiment (hardware) is

powered off. Figure 4: State Transition Table Description When Device is powered on, the module goes to initialization state. The module goes into Integrity check then performs self-tests. The module is not operational until the self tests are completed successfully. Upon successful completion of the self tests, the module enters the Operational State. While the module is in the Operational State, it performs selected continuous testing. The module will return an error state output if the integrity check fails or the self tests are not yet completed. If no more operations are performed and hardware is powered off, the module will go to power off state. Crypto Officer Guidance The crypto officer is responsible for initializing the crypto module within its operational boundary. Refer Crypto Officer Services segment for available APIs to perform the task at hand. The officer shall ensure that the module has proceeded to the Operational State upon successful initialization. Crypto officers shall ensure that the best practices of the Module usage is followed throughout the application operational sphere. Crypto User Guidance The crypto user is able to access the module using the API defined in Crypto User Services segment. The crypto user shall ensure the best practices outlined in the Module APIs usage are followed with the guidance of Crypto officers. Approved Mode of Operation The conditions for using the module in the Approved Mode of Operation are:

1. The module is a cryptographic library and is intended to be used with a calling application.
2. The calling application must invoke the init routine to put the module into the Approved Mode of Operation. All data output will be inhibited otherwise. ® denotes a trademark of Geotab Inc., which may be registered in certain countries This document may freely be reproduced and distributed in its entirety.

The following procedure will properly initialize the module: ● Run gc_init command as CO Non-Compliant State Failure to follow the directions in the rules noted in this section will result in the module operating in a non-compliant state, which is considered out of scope of this validation. 12. Mitigation of Other Attacks The module does not claim to mitigate any additional attacks. ® denotes a trademark of Geotab Inc., which may be registered in certain countries This document may freely be reproduced and distributed in its entirety.