Copyright Broadcom 2016. May be reproduced only in its original entirety [without revision].
BCM58100B0 Series:
BCM58101B0, BCM58102B0,
BCM58103B0
Cryptographic Module VC0
Non-Proprietary Security Policy
Document Version 0.8
Broadcom Ltd.
Revision Date: 2016-05-25
Broadcom Ltd. BCM58100B0 Series Cryptographic Module Security Policy Version 0.8 2016-05-25
Page 2
TABLE OF CONTENTS
1. MODULE OVERVIEW .........................................................................................................................................3
2. SECURITY LEVEL................................................................................................................................................5
3. MODES OF OPERATION.....................................................................................................................................6
4. PORTS AND INTERFACES .................................................................................................................................7
5. IDENTIFICATION AND AUTHENTICATION POLICY................................................................................9
6. ACCESS CONTROL POLICY............................................................................................................................10
DEFINITION OF SERVICES.........................................................................................................................................10
DEFINITION OF CRITICAL SECURITY PARAMETERS (CSPS)......................................................................................14
DEFINITION OF CSPS MODES OF ACCESS ................................................................................................................20
7. OPERATIONAL ENVIRONMENT....................................................................................................................22
8. SECURITY RULES .............................................................................................................................................22
9. PHYSICAL SECURITY POLICY ......................................................................................................................25
PHYSICAL SECURITY MECHANISMS.........................................................................................................................25
10. MITIGATION OF OTHER ATTACKS POLICY...........................................................................................26
11. REFERENCES ....................................................................................................................................................26
12. DEFINITIONS AND ACRONYMS...................................................................................................................26
Broadcom Ltd. BCM58100B0 Series Cryptographic Module Security Policy Version 0.8 2016-05-25
Page 3
1. Module Overview
The BCM58100B0 Series Cryptographic Module, a single-chip encased in hard opaque tamper
evident IC packaging, is a highly integrated system on a chip. It is marketed in three part
numbers.
• BCM58101B0 : integrated system on a chip with no NFC capabilities
• BCM58102B0 : integrated system on a chip with NFC capabilities
• BCM58103B0 : integrated system on a chip with enhanced NFC capabilities
All devices use the same physical package.
The module runs firmware version rev0.
Figure 1 shows that the BCM58100B0 Series is composed of two components, the BCM5810X
component and the NFC component. These modules are interconnected with a SPI (Serial
Peripheral Interface bus) connection. The NFC component is purely a peripheral block to
BCM5810X for NFC communication. No cryptographic implementation is included in this
component; all cryptographic capabilities are encapsulated in the BCM5810X component. The
interconnect between BCM5810X and NFC is for data communication only, no cryptographic
material or key is passed between the modules.
Figure 1 BCM58100B0 Top Level Blocks
BCM5810X
NFC
SPI Data
Connection
5810x Package
For the purpose of FIPS140-2 certification the physical boundary of the chip is used as the
security boundary of the cryptographic module.
The BCM58100B0 Series Cryptographic Module’s FIPS boundary is defined as:
• The external surface of the BCM58100B0 chip including the hard opaque encapsulating
material that physically protects all module components.
The algorithm boundary is defined as the BCM5810X component.
The figures below illustrate the cryptographic module’s physical boundary, interfaces, and
logical software execution contexts within the physical boundary.
Broadcom Ltd. BCM58100B0 Series Cryptographic Module Security Policy Version 0.8 2016-05-25
Page 4
Figure 2 - Image of the Cryptographic Module Physical Boundary
BCM58102B0KFBG
TAYYWW P20
P083 P1
(Top) (Bottom)
Figure 3 - Pictures of the Cryptographic Module Physical Boundary
(Top) (Bottom)
Broadcom Ltd. BCM58100B0 Series Cryptographic Module Security Policy Version 0.8 2016-05-25
Page 5
Figure 4 - Block Diagram of module Interfaces & logical Software Execution Contexts
58100 Cryptographic Module
Command Parser
USB application
runs in user mode,
accessible to
memory region
allocated by the
Memory Protection
Unit of M3.
SCAPI
(Standardized API
layer to access
module crypto HW
or crypto
primitives.)
Approved Crypto
Algorithms
USB
Host System
- Control Input
- Status output
- Data input
- Data output
SPI
Flash
Secure Boot Image (SBI)
- Data / Code output
Clock
- Control Input
- Status output
Reset Pins
- Control Input
- Status output
Power
Dedicated IO
and core power
supply pins
separated from
signal pins
UART
- Error Status output
2. Security Level
The cryptographic module meets the overall requirements applicable to Level 3 security of
FIPS 140-2.
Table 1 - Module Security Level Specification
Security Requirements Section Level
Cryptographic Module Specification 3
Module Ports and Interfaces 3
Roles, Services and Authentication 3
Finite State Model 3
Physical Security 3
Operational Environment N/A
Cryptographic Key Management 3
EMI/EMC 3
Broadcom Ltd. BCM58100B0 Series Cryptographic Module Security Policy Version 0.8 2016-05-25
Page 6
Self-Tests 3
Design Assurance 3
Mitigation of Other Attacks NA
3. Modes of Operation
FIPS Approved mode of operation
The BCM58100B0 Series cryptographic module supports a single FIPS Approved mode of
operation. The user can determine that the cryptographic module is running in FIPS Approved
mode of operation when the status output RESET_OUT_L is high. The module does not support
a non-Approved mode of operation.
Approved Algorithms
The module implements the following approved and allowed cryptographic algorithms using a
hardware crypto engine called [SMAU - Crypto/Auth] block. The same hardware block is used
twice in the Secure Memory Access Unit or SMAU. One instance is being used for offloading
generic cryptographic operations. The other instance is being used to support secure caching of
instruction and data stored externally in encrypted and integrity-protected format. Individual
self-tests are conducted after power-on to test the instantiation for generic cryptographic
operations. Each algorithm implementation is used during different scenarios. They are never
used simultaneously for the same operation. Each algorithm implementation has its own
algorithm certificate and has its own power-on Self-test.
Table 2 – Approved Algorithms
Cryptographic Algorithm Description Certificate Number
AES [SMAU – Crypto/Auth] block, ECB, CBC,
CTR
Key size : 128, 192, 256
#3762
AES CCM [SMAU – Crypto/Auth] block
Key size : 128, Nonce Len 12, Tag Len 4, 8,
12, 16
#3763
HMAC- SHA256 [SMAU – Crypto/Auth] block
#2462
SHA256 [SMAU – Crypto/Auth] block
#3132
Broadcom Ltd. BCM58100B0 Series Cryptographic Module Security Policy Version 0.8 2016-05-25
Page 7
DRBG SP800-90 DRBG, SHA-256 is the HASH
functions used
#1034
ECDSA Signature generation, signature verification
256-bit key, curve P-256
#807
DSA Signature generation, signature verification
2048-bit key, with SHA-256 for signature
generation #1045
RSA Signature generation, signature verification
2048-bit key with SHA-256
#1936
Allowed Non-Approved Algorithms
The module implements the following non-approved cryptographic algorithms
EC Diffie-Hellman: Non-SP800-56A Compliant ECDH allowed per FIPS 140-2
Implementation Guidance D.8 (key agreement; key establishment methodology provides 128-
bits of encryption strength)
NDRNG – internal module source utilizing free running oscillators to capture thermal noise as
the source of randomness. The NDRNG is used to collect entropy to be fed to the FIPS SP800-
90A DRBG.
4. Ports and Interfaces
The BCM58100 Series Cryptographic Module provides physical ports as listed in Table 3 below.
Table 3 – Physical Ports
Note: the BCM5810X chip has a total of 141 signal pins. Each BCM5810X Interface Group
listed in Table 3 contains several BCM58100B0 pins. Unused Interface Groups will be marked
as “Non-Available” because they are currently disabled by the cryptographic module.
Clock group Control Input
Status Output
Clock
- 25MHz clock
- 32KHz clock
Clock output
- 25MHz clock output
Reset group Control input One reset input
Broadcom Ltd. BCM58100B0 Series Cryptographic Module Security Policy Version 0.8 2016-05-25
Page 8
Status output Reset output : Indicates that
system power supply is stable.
Secure boot Control Input
Status Output
- one key zeroization request
input
- Ten external tamper detection
(e.g. can be hooked up to a
temperature sensor or a voltage
sensor. No claims made for
FIPS mode).
- One ERROR status.
SPI group:
All Code/Data Input is
authenticated by the module.
Data input (code and data) Code and data from SPI flash
(clock, device select, and four
data I/O)
USB group:
Device interface used by the
module’s operators to make
service requests. Requests are
authenticated via the ECDH
secure session.
Data input
Data output
Control input
Status output
Service request input
Service response output
(USB differential data bus)
UART group:
UART0 port is enabled as
error status output.
Output UART ports are
disabled and logic is put in
reset state.
Status output
Other UART ports are
intended for future use:
Data input
Data output
Status output
(Four UART ports of four
signals each.)
Intended use in the future:
Data received or transmitted for
UART console application
Static Memory Interface
group:
Clock to the group block is
disabled and logic is put in
reset state.
Non-available
Intended use in the future:
Data input
Data output
Non-available
(chip select, read/write control, 8
data bit, 20 address bit)
Intended use in the future :
Code and data from SRAM or
flash memory.
NFC group BCM58102 and
BCM58103:
Data input
Data output
(Four antenna connections, two
SWP interface ports.):
Data received or transmitted for
contactless smart card
applications.
Smart Card group:
Clock to the group block is
disabled and logic is put in
reset state.
Non-available
Intended use in the future:
Data input
Data output
Non-available
(Seven interface signals)
Intended use in the future:
Data received or transmitted For
contacted Smart Card
applications.
JTAG group:
Completely disabled by HW
Non-available Non-available
Broadcom Ltd. BCM58100B0 Series Cryptographic Module Security Policy Version 0.8 2016-05-25
Page 9
in FIPS mode.
Module HW\FW\SW enforces
that non-volatile plaintext
critical security parameters
cannot be shared, used, or
viewed in FIPS mode.
Power group Power is distributed to
the chip using
designated IO and core
power pins that are
completely separated
from any signal pin
groups.
Power pins are only
connected to the
internal power planes
of the silicon chip.
Over 50 power and ground pins.
5. Identification and Authentication Policy
Assumption of roles
The BCM58100B0 Series Cryptographic Module supports two operator roles, User and
Cryptographic-Officer. Only the authorized user (in either role) could establish a secure session
with the cryptographic module. The module is designed to operate with a single entity that is
assigned the User and Cryptographic-Officer roles. The user identity is embedded in the
module’s SBI during manufacturing (Secure Boot Image: an authenticated software extension of
the module’s BOOT ROM. SBI software is part of the BCM58100B0 Series Cryptographic
Module). The cryptographic module implements identity-based operator authentication to allow
only the authorized user to access cryptographic services.
Authentication is accomplished via a 256-bit ECDSA-based signature verification process. A
single 256-bit ECDSA public key is embedded in the SBI. The 256-bit ECDSA public key is
used to authenticate the operator during the establishment of an ECDH secure session between
the module and the operator on the external host system.
After an operator is authenticated successfully, the operator can assume either the role of the
Cryptographic Officer or the role of the User. The module allows the operator to perform both
CO and User services.
Broadcom Ltd. BCM58100B0 Series Cryptographic Module Security Policy Version 0.8 2016-05-25
Page 10
Table 4 - Roles and Required Identification and Authentication
Role Type of Authentication Authentication Data
User Identity-based operator
authentication
• 256-bit ECDSA
signature verification
Cryptographic-Officer Identity-based operator
authentication
• 256-bit ECDSA
signature verification
Table 5 - Strengths of Authentication Mechanisms
Authentication Mechanism Strength of Mechanism
ECDSA Signature Verification (256 bit) The probability that a random attempt will
succeed or a false acceptance will occur is
1/2128
which is less than 1/1,000,000.
The probability of successfully authenticating
to the module within one minute is 3,750/2128
which is less than 1/100,000. The module will
only allow one attempt to verify the operator –
if that attempt fails the module will be in an
error state and must be rebooted to try and
become operational again. Please see section
“8. Security Rules” below (security rules
imposed by the vendor) for the detail
supporting this calculation.
6. Access Control Policy
Definition of Services
The cryptographic module supports the following authenticated services defined in Table 5:
Table 6 - Authenticated Services
Name of Service Description of Service
Generate Key This service generates an AES or HMAC key to be used during
operator requested services.
AES Encrypt This service encrypts bulk operator supplied data using a
Broadcom Ltd. BCM58100B0 Series Cryptographic Module Security Policy Version 0.8 2016-05-25
Page 11
previously generated AES key.
AES Decrypt This service decrypts bulk operator supplied data using a
previously generated AES key.
SHA-256 Hashing This service generates a SHA-256 digest on supplied data.
Load Key This service allows an operator to load a key into the module’s key
cache.
The key being loaded can be a private key or a public key of an
asymmetrical key pair, or a symmetrical key for AES or HMAC.
All keys loaded via this service are being protected by the ECDH
secure session via 128-bit AES-CCM encryption and integrity
protection.
RSA Signature
Verification
This service performs RSA Signature Verification on operator
supplied data with a previously loaded public key (see service
“Load Key”).
DSA Signature
Verification
This service performs DSA Signature Verification on operator
supplied data with a previously loaded public key (see service
“Load Key”).
ECDSA Signature
Verification
This service performs ECDSA Signature Verification on operator
supplied data with a previously loaded public key (see service
“Load Key”).
RSA Signature
Generation
This service performs RSA Signature Generation on operator
supplied data with a previously loaded private key (see service
“Load Key”).
DSA Signature
Generation
This service performs DSA Signature Generation (2048 bit key)
on operator supplied data with a previously loaded private key (see
service “Load Key”).
ECDSA Signature
Generation
This service performs ECDSA Signature Generation on operator
supplied data with a previously loaded private key (see service
“Load Key”).
Generate Random
Number
This service generates a random number with the module’s FIPS
800-90A DRBG and outputs the generated random number to the
requesting operator.
EC Diffie-Hellman Key This service is comprised of several steps which establish a session
Broadcom Ltd. BCM58100B0 Series Cryptographic Module Security Policy Version 0.8 2016-05-25
Page 12
Exchange key between the module and an external entity.
HMAC Request Compute an HMAC on an operator supplied blob of data.
The cryptographic module supports the following unauthenticated services defined in Table
7:
Table 7 - Unauthenticated Services
Name of Service Description of Service
Self Test This service executes the suite of self-tests required by FIPS 140-
2. Self-tests are invoked by power cycling the module.
Show Status This service provides the current status of the cryptographic
module.
Get Info This service computes and outputs the ECDSA device public key
of the cryptographic module
Get Version This service returns the version/revision information of the
cryptographic module
Zeroize • Power-cycle or hard reset will zeroize all volatile critical
security parameters including internally generated CSPs or
loaded keys.
• When the MANU_DEBUG pin within the Secure Boot group
physical interface is turned high all volatile and non-volatile
plaintext critical security parameters will be zeroized – after
this the module will not boot again.
Table 8 - Specification of Service Inputs & Outputs
Service Control Input Data Input Data Output Status Output
Generate Key Key Type N/A Key Handle Success/fail
AES Encrypt Length
Key Handle
Plaintext Ciphertext Success/fail
AES Decrypt Length
Key Handle
Ciphertext Plaintext Success/fail
SHA-256
Hashing
Hash Type Data Blob Digest Success/fail
Load Key Key Type
Key Handle
Key N/A Success/fail
Broadcom Ltd. BCM58100B0 Series Cryptographic Module Security Policy Version 0.8 2016-05-25
Page 13
Service Control Input Data Input Data Output Status Output
RSA Signature
Verification
Hash Length
Key Handle
Hash Blob
Signature
N/A Success/fail
DSA Signature
Verification
Hash Length
Key Handle
Hash Blob
Signature
N/A Success/fail
ECDSA
Signature
Verification
Hash Length
Key Handle
Hash Blob
Signature
N/A Success/fail
RSA Signature
Generation
Hash Length
Key Handle
Hash Blob Signature Success/fail
DSA Signature
Generation
Hash Length
Key Handle
Hash Blob Signature Success/fail
ECDSA
Signature
Generation
Hash Length
Key Handle
Hash Blob Signature Success/fail
Generate
Random
Number
DRBG Type
Length
N/A Random Number Success/fail
ECDiffie-
Hellman Key
Exchange
(comprised of
two steps)
Header info. ECDiffie-Hellman
key establishment
data received from
Host System
ECDiffie-Hellman
key establishment
data sent to Host
System
Success/fail
HMAC Request Length
Hash Type
Key Handle
Data Blob MAC Success/fail
Self Test N/A
(Power cycle)
N/A N/A Success/fail
Show Status N/A N/A N/A
All the above Status
Output (Table 6
Specification of
Service Inputs &
Outputs)
Status Output of
Interface groups
(Table 2 Physical
Ports)
Get Info N/A N/A Cryptographic
Module device
public key
Success/fail
Broadcom Ltd. BCM58100B0 Series Cryptographic Module Security Policy Version 0.8 2016-05-25
Page 14
Service Control Input Data Input Data Output Status Output
KDI-EC-PUB
Get Version N/A N/A Version and
Revision
information of the
Cryptographic
Module
Success/fail
Zeroize Power-cycle, hard
reset, or set
MANU_DEBUG
pin
N/A N/A
N/A
Definition of Critical Security Parameters (CSPs)
The following are the CSPs contained in the module.
Table 9 - Secret and Private Keys
Key Description/Usage Generation Storage Entry/Output Destruction
KECDH-
PRIV
256 bit
random
number
used for
ephemeral
ECDH key.
Used to establish an
ECDH based session
key.
Ephemeral key
generated
internally via
DRBG per
SP800-90A.
Stored in plaintext
internally in the
module’s [Scratch
RAM] block.
Key-to-entity
association:
associated with a
session ID during
the ECDH secure
session
establishment.
Entry: N/A
Entry Key-to-
entity association:
N/A
Output: N/A
Output Key-to-
entity association:
N/A.
Zeroize service.
Additionally always
destroyed after the
symmetrical session
key is established.
Broadcom Ltd. BCM58100B0 Series Cryptographic Module Security Policy Version 0.8 2016-05-25
Page 15
Key Description/Usage Generation Storage Entry/Output Destruction
KAES
128 bit
AES key.
A unique
value for
each
module.
Used to encrypt and
decrypt the Secure
Boot Image (SBI)
when the SBI is loaded
(symmetrically).
Generated
internally during
manufacturing
via DRBG per
SP800-90A.
Stored in plaintext
internally in OTP.
When in use it is
temporality copied
to the [Scratch
RAM] block.
Key-to-entity
association:
Key index = 2 in
OTP.
Entry: N/A
Entry Key-to-
entity association:
N/A
Output: N/A
Output Key-to-
entity association:
N/A.
Zeroize service.
Temporary copy in
[Scratch RAM]
block always
destroyed after each
reset cycle.
KHMAC
256 bit
HMAC-
SHA-256
key. A
unique
value for
each
module.
Used to protect and
verify the SBI.
Generated
internally during
manufacturing
via DRBG per
SP800-90A.
Stored in plaintext
internally in OTP.
When in use it is
temporality copied
to the [Scratch
RAM] block.
Key-to-entity
association:
Key index = 3 in
OTP.
Entry: N/A
Entry Key-to-
entity association:
N/A
Output: N/A
Output Key-to-
entity association:
N/A.
Zeroize service.
Temporary copy in
[Scratch RAM]
block always
destroyed after each
reset cycle.
KDI-EC-
PRIV
256 bit
ECDSA
private key.
A unique
value for
each
module.
Used to establish the
mutually authenticated
ECDH secure session
communication
channel between the
module and an
external entity. Used
as the identity key of
the module in these
authenticated
communications.
Generated
internally during
manufacturing
via DRBG per
SP800-90A.
Stored in plaintext
internally in OTP.
When in use it is
temporality copied
to the [Scratch
RAM] block.
Key-to-entity
association:
Key index = 4 in
OTP.
Entry: N/A
Entry Key-to-
entity association:
N/A
Output: N/A
Output Key-to-
entity association:
N/A.
Zeroize service.
Temporary copy in
[Scratch RAM]
block always
destroyed after each
reset cycle.
Broadcom Ltd. BCM58100B0 Series Cryptographic Module Security Policy Version 0.8 2016-05-25
Page 16
Key Description/Usage Generation Storage Entry/Output Destruction
KAPP-AES
128, 192 or
256 bit
AES keys.
Used to
encrypt/decrypt
application data when
external applications
issue encrypt or
decrypt service
requests.
Generated
internally during
operation via
DRBG per
SP800-90A. See
Generate Key
service.
Stored in the
volatile “key cache”
within the [Scratch
RAM] block.
Key-to-entity
association:
“key cache” handle.
Note this handle is
given by the
application that
requested the
creation of the key
so that application
can request
encryption/
decryption with the
key at a later point
in time.
Entry: Entered
into the module by
Load Key service1
Entry Key-to-
entity association:
Session key
derived during the
ECDiffie-Hellman
Key Exchange
service.
Output: N/A
Output Key-to-
entity association:
N/A.
Zeroize service.
Temporary copy in
[Scratch RAM]
block always
destroyed after each
reset cycle.
KAPP-
HMAC
256 bit
HMAC
keys
(SHA-
256).
Used to protect and
verify application data
when external
applications issue
protection or
verification service
requests.
Generated
internally during
operation via
DRBG per
SP800-90A. See
Generate Key
service.
Stored in the
volatile “key cache”
within the [Scratch
RAM] block.
Key-to-entity
association:
“key cache” handle.
Note this handle is
given by the
application that
requested the
creation of the key
so that application
can request
protection/
verification with the
key at a later point
in time.
Entry: Entered
into the module by
Load Key service
Entry Key-to-
entity association:
Session key
derived during the
ECDiffie-Hellman
Key Exchange
service.
Output: N/A
Output Key-to-
entity association:
N/A.
Zeroize service.
Temporary copy in
[Scratch RAM]
block always
destroyed after each
reset cycle.
1
192 and 256-bit keys entered using the Load Key service only provide 128-bits of security strength.
Broadcom Ltd. BCM58100B0 Series Cryptographic Module Security Policy Version 0.8 2016-05-25
Page 17
Key Description/Usage Generation Storage Entry/Output Destruction
KAPP-PRIV
2048 bit
DSA
2048 bit
RSA
256 bit
ECDSA
Used to perform
signature generation
during the RSA, DSA
or ECDSA Signature
services.
N/A Multiple instances.
Stored in the
volatile “key cache”
within the [Scratch
RAM] block.
Key-to-entity
association:
“key cache” handle.
Note this handle is
given by the
application that
requested the entry
of the key so that
the application can
request signature
generation with the
key at a later point
in time.
Entry: Entered
into the module by
Load Key service
Entry Key-to-
entity association:
This is a private
key that is
associated with the
public key
member of a key-
pair.
Output: N/A
Output Key-to-
entity association:
N/A.
When the zeroize
service is requested.
Always destroyed
after each reset
cycle.
KECDH-SS
256 bit
ephemeral
ECDH
shared
secret.
Used to derive the
session key Kss
Derived using
ECDH key
exchange
algorithm based
on KECDH-PRIV
and KECDH-OP-
PUB
Stored only
temporarily stored
in the scratch RAM,
erased after Kss is
derived
Key-to-entity
association:
associated with a
session ID during
the ECDH secure
session
establishment.
Entry: N/A
Entry Key-to-
entity association:
N/A
Output: N/A
Output Key-to-
entity association:
N/A.
Zeroize service.
Additionally always
destroyed after the
symmetrical session
key is established.
Kss
128 bit
AES key.
Session key derived
during the ECDiffie-
Hellman Key
Exchange service. The
module will use this
key for secure
communications
to/from the external
host system.
Generated during
the ECDiffie-
Hellman Key
Exchange service
via SHA256-
based KDF
function.
Stored in the
volatile “key cache”
within the [Scratch
RAM] block.
Key-to-entity
association:
Only one session
key exists at any
given point in time.
Entry: N/A
Entry Key-to-
entity association:
N/A
Output: N/A
Output Key-to-
entity association:
N/A.
Zeroize service.
Temporary copy in
[Scratch RAM]
block always
destroyed after each
reset cycle.
Broadcom Ltd. BCM58100B0 Series Cryptographic Module Security Policy Version 0.8 2016-05-25
Page 18
Key Description/Usage Generation Storage Entry/Output Destruction
DRBG
Seed
512 bits
Entropy value fed to
the SP800-90A.
Gathered from
internal module
NDRNG utilizing
free running
oscillators to
capture thermal
noise.
Generated via
NDRNG and stored
in DRBG registers
Key-to-entity
association:
Only one DRBG
seed key exists at
any given point in
time.
Entry: N/A
Entry Key-to-
entity association:
N/A
Output: N/A
Output Key-to-
entity association:
N/A.
Reset DRBG or
power cycle the
chip.
DRBG
State
(values
V and C)
State of the module’s
SP800-90A.
Generated within
the module’s
SP800-90A
DRBG.
Stored in DRBG
registers.
Key-to-entity
association:
The DRBG
maintains one state
at a given time.
Entry: N/A
Entry Key-to-
entity association:
N/A
Output: N/A
Output Key-to-
entity association:
N/A.
Reset DRBG or
power cycle the
chip.
Definition of Public Keys:
The following are public keys contained in the module.
Table 10 - Public Keys
Key Description/Usage Generation Storage Entry/Output
KDI-EC-PUB
256 bit ECDSA
public key. A
unique value
for each
module.
Used by the operator to
authenticate the
cryptographic module in a
mutually authenticated
secure session
Computed
internally upon
each get_info
request per
ECDSA
algorithm
Stored only stored
temporarily in the
scratch RAM
during the
processing of the
get_info service
Key-to-entity
association:
Public part of the
device identity key.
Entry: N/A
Entry Key-to-entity
association: N/A
Output: as the result
of get_info service
Output Key-to-entity
association:
embedded in the
get_info command
response.
Broadcom Ltd. BCM58100B0 Series Cryptographic Module Security Policy Version 0.8 2016-05-25
Page 19
Key Description/Usage Generation Storage Entry/Output
KECDH-PUB
256 bit public
ephemeral
ECDH key of
the
cryptographic
module
Used to establish an ECDH
based session.
Ephemeral public
key generated
internally for on
non- SP800-56A
compliant ECDH
Stored only stored
temporarily in the
scratch RAM
during the process
of establishing the
ECDH session,
erased after the
session key is
established
Key-to-entity
association:
Public key of the
ephemeral ECDH
key pair.
Entry: N/A
Entry Key-to-entity
association: N/A
Output: as the result
of the ECDH key
exchange
Output Key-to-entity
association:
embedded in the
command response
for ECDH key
exchange.
KECDH-OP-
PUB
256 bit public
ephemeral
ECDH key of
the operator
Used to establish an ECDH
based session.
Ephemeral public
key generated
and signed by the
operator, pass
into the
cryptographic
module during
ECDH session
key exchange
Stored only stored
temporarily in the
scratch RAM
during the process
of establishing the
ECDH session,
erased after the
session key is
established
Key-to-entity
association:
Associated with the
authentication
session. Only one
session is active.
Entry: input of the
ECDH key exchange
Entry Key-to-entity
association:
embedded in the
command for ECDH
key exchange.
Output: NA
Output Key-to-entity
association: NA
KAPP-PUB
2048 bit DSA
2048 bit RSA
256 bit ECDSA
Used to perform signature
verification during the RSA,
DSA or ECDSA Signature
Verification services.
N/A Stored in the
volatile “key cache”
within the [Scratch
RAM] block on the
block diagram.
Key-to-entity
association:
“key cache” handle.
Note this handle is
passed back to the
application that
requested the entry
of the key so that
the application can
request signature
verification with the
key at a later point
in time.
Entry: Entered into
the module by the
Load Key service.
Entry Key-to-entity
association: This is a
public key that is
associated with the
private key member of
a key-pair.
Output: N/A
Output Key-to-entity
association: N/A.
Broadcom Ltd. BCM58100B0 Series Cryptographic Module Security Policy Version 0.8 2016-05-25
Page 20
Key Description/Usage Generation Storage Entry/Output
KOP-PUB
256 bit ECDSA
Operator’s public key
Used to authenticate the
operator during an ECDH
secure session.
N/A Stored in the on-
chip RAM.
Key-to-entity
association:
This key is located
at a fixed offset of
the SBI image
known to the
implementation of
the cryptographic
module.
Entry: Embedded in
the SBI during the
manufacturing
process.
Entry Key-to-entity
association: This is a
public key that is
associated with the
private key member of
a key-pair.
Output: N/A
Output Key-to-entity
association: N/A.
Definition of CSPs Modes of Access
Table 9 defines the relationship between access to CSPs and the different module services. The
modes of access shown in the table are defined as:
• G = Generate: The module generates the CSP.
• R = Read: The module reads the CSP. The read access is typically performed before the
module uses the CSP.
• W = Write: The module writes the CSP. The write access is typically performed after a
CSP is imported into the module, or the module generates a CSP, or the module
overwrites an existing CSP.
• Z = Zeroize: The module zeroizes the CSP.
Table 11 - CSP Access Rights within Roles & Services
Role Service Cryptographic Keys and CSPs Access Operation
C.O. User
X X Generate Key G KAPP-AES
G KAPP-HMAC
For each service call a handle to the generated key will be
passed back to the operator.
X X AES Encrypt R KAPP-AES
For each service request the operator will indicate which
KAPP-AES key to use by passing in the key’s handle as input.
Broadcom Ltd. BCM58100B0 Series Cryptographic Module Security Policy Version 0.8 2016-05-25
Page 21
X X AES Decrypt R KAPP-AES
For each service request the operator will indicate which
KAPP-AES key to use by passing in the key’s handle as input.
X X SHA-256
Hashing
N/A
X X Load Key W KAPP-PUB
W KAPP-AES
W KAPP-HMAC
For each service request a handle to the loaded key will be
passed back to the operator.
X X RSA
Signature
Verification
R KAPP-PUB
For each service request the operator will indicated which
KAPP-PUB RSA key to use by passing in the key’s handle as
input.
X X DSA
Signature
Verification
R KAPP-PUB
For each service request the operator will indicated which
KAPP-PUB DSA key to use by passing in the key’s handle as
input.
X X ECDSA
Signature
Verification
R KAPP-PUB
For each service request the operator will indicated which
KAPP-PUB ECDSA key to use by passing in the key’s handle
as input.
X X RSA
Signature
Generation
R KAPP-PRIV
For each service request the operator will indicated which
KAPP-PRIV RSA key to use by passing in the key’s handle as
input.
X X DSA
Signature
Generation
R KAPP-PRIV
For each service request the operator will indicated which
KAPP-PRIV DSA key to use by passing in the key’s handle as
input.
X X ECDSA
Signature
Generation
R KAPP-PRIV
For each service request the operator will indicated which
KAPP-PRIV ECDSA key to use by passing in the key’s handle
as input.
X X Generate
Random
Number
R DRBG Seed (note: a new Seed is generated for each call
to service Generate Random Number).
R DRBG Internal State
The DRBG is seeded with the Seed. The random number
Broadcom Ltd. BCM58100B0 Series Cryptographic Module Security Policy Version 0.8 2016-05-25
Page 22
generated by the DRBG is returned to the operator
requesting the service.
X X ECDiffie-
Hellman Key
Exchange
R KDI-EC-PRIV
R KECDH-PRIV
R KOP-PUB
G KECDH-PUB
R KECDH-OP-PUB
G KECDH-SS
G Kss
The operator establishes a secure ECDH key exchange
session with a derived session key Kss
X X HMAC Request R KAPP-HMAC
For each service request the operator will indicated which
key to use by passing in key handles as input.
X X Self Test N/A
X X Show Status N/A
X X Gen Info R KDI-EC-PUB
X X Gen Version NA
7. Operational Environment
The FIPS 140-2 Area 6 Operational Environment requirements are not applicable because the
module does not contain a modifiable operational environment.
8. Security Rules
This section documents the security rules enforced by the BCM58100 Series Cryptographic
Module to implement the security requirements for a FIPS 140-2 Level 3 module.
1. The module indicates when the device is in the Approved mode of operation.
2. The module implements one approved mode of operation. Power-cycling zeroizes all
volatile plaintext critical security parameters.
3. Prior to completion of all FIPS power-on self-tests the module performs several
special initialization period functions (e.g., RAM Memory BIST Read/Write, and
OTP Checksum). Failure during these special initialization period functions causes a
chip reset. Subsequent to the special initialization period functions any failure in a
FIPS power-on self-test cause the ERROR status to be issued followed by a chip
reset.
4. No hardware, software, or firmware components of the cryptographic module are
excluded from the security requirements of FIPS 140-2.
Broadcom Ltd. BCM58100B0 Series Cryptographic Module Security Policy Version 0.8 2016-05-25
Page 23
5. The module restricts all information flow and physical access points to physical ports
and logical interfaces that define all entry and exit points to and from the module.
6. All data output via the data output interface are inhibited when an error state exists
and during self-tests.
7. The output data paths are logically disconnected from the circuitry and processes that
perform key generation, and key zeroization.
8. The module never outputs plaintext cryptographic keys or CSPs or sensitive data.
9. Status information never contains CSPs or sensitive data that if misused could lead to
a compromise of the module
10. The module provides two operator roles. These are the User role, and the
Cryptographic-Officer role.
11. The module does not support concurrent operators.
12. The module does not support a maintenance role.
13. The module does not support a bypass capability.
14. The module supports identity-based authentication.
15. When the module is powered off and subsequently powered on, the results of
previous authentications are not retained and the module requires the operator to be
re-authenticated.
16. Authentication data within the module is protected against unauthorized disclosure,
modification, and substitution.
17. The module contains the authentication data required to authenticate the operator for
the first time.
18. For each attempt to use the authentication mechanism the probability is less than one
in 1,000,000 that a random attempt will succeed or a false acceptance will occur.
19. For multiple attempts to use the authentication mechanism during a one-minute
period the probability is less than one in 100,000 that a random attempt will succeed
or a false acceptance will occur.
20. The module’s authentication mechanism does not supply any feedback information to
the operator.
21. Recovery from “soft” error states is possible via power-cycling. Recovery from
“hard” error states is not possible.
22. The module is physically protected with a production-grade hard opaque tamper
evident encapsulating material.
23. The module does not contain any doors or removable covers.
24. Secret keys, private keys, and CSPs within the module are protected from
unauthorized disclosure, modification, and substitution.
25. Public keys within the module are protected against unauthorized modification and
Broadcom Ltd. BCM58100B0 Series Cryptographic Module Security Policy Version 0.8 2016-05-25
Page 24
substitution.
26. Cryptographic keys generated by the module are generated using Approved key
generation methods: FIPS 186-4 Appendix 3.1.
27. Compromising the security of the key generation methods requires as least as many
operations as determining the value of the generated keys.
28. Seed keys are not entered into the module during the key generation process, they are
gathered internally.
29. Intermediate key generation values are not output from the module.
30. Key establishment is performed via non-SP 800-56A ECDH (allowed as per FIPS
140-2 Implementation Guidance D.8).
31. Compromising the security of the key establishment method (2128
) requires as many
operations as determining the value of the cryptographic key being agreed upon
(2128
).
32. The module does not support manual key entry.
33. All secret and private keys entered into the module must be encrypted with an ECDH
session key, 128-bit AES-CCM mode key.
34. The module does not support key entry via split knowledge procedures.
35. The module does not support a SW/FW Load service.
36. The module provides a method to zeroize all plaintext secret and private
cryptographic keys and CSPs within the module (ZEROIZE PIN within the Secure
Boot group physical interface turned high).
37. The module conforms to the EMI/EMC requirements specified by 47 Code of Federal
Regulations, Part 15, Subpart B, Unintentional Radiators, Digital Devices, Class B
(i.e., for home use).
38. The module performs the following self-tests:
a. Power up Self-Tests:
i. Cryptographic algorithm tests:
• AES [SMAU – Generic Crypto/Auth] block KAT; encryption and
decryption are done.
• HMAC SHA256 [SMAU – Generic Crypto/Auth] block KAT,
covers SHA256.
• DRBG SP800-90A KAT.
• RSA, signature generation and signature verification KATs.
Key size of 2048 bit; hash size of 256 bit.
• DSA, signature generation and signature verification PCT.
Key size of 2048 bit; hash size of 256 bit.
• ECDSA signature generation and signature verification KATs.
Key size of 256 bit.
• Non-SP SP800-56A ECDH:
Broadcom Ltd. BCM58100B0 Series Cryptographic Module Security Policy Version 0.8 2016-05-25
Page 25
• DLC primitives KAT.
• Key Agreement KAT.
• Key Derivation Function KAT.
ii. Firmware Integrity Test:
• BootROM: 32 bit checksum.
• Secure Boot Image, SBI the authenticated software extension of
the module’s Secure Boot Loader, is authenticated by Secure Boot
Loader code when Secure Boot Loader code loads the SBI.
Authentication is accomplished via 256 HMAC verification (the
module also decrypts the SBI image with its 128 bit AES CSP,
KAES).
iii. Critical Functions Tests:
• Memory BIST (Read/Write)
• OTP Checksum Verification
b. Conditional Self-Tests:
i. Continuous Random Number Generator test – performed on NDRNG
and DRBG. Block size for NDRNG test is 32 bytes.
ii. Pair-wise consistency test for generated ECDH key pair.
39. The operator is capable of commanding the module to perform the power-up self-test
via power cycling.
40. After a secure session is established, all data transfer between the operator and the
cryptographic module is encrypted. Any key and secure material that enters and exits
the cryptographic module is encrypted.
This section documents the security rules imposed by the vendor:
1. The module does not support the update of the logical serial number or vendor ID.
2. Each 256-bit ECDSA operation takes > 8ms to perform. For each authentication attempt,
the cryptographic module has to perform two ECDSA operations, one for ECDSA
signature generation and the other for ECDSA signature verification before the operator
can be authenticated. The operator can make no more than 3750 attempts in every minute
even if attempts were made continuously.
9. Physical Security Policy
Physical Security Mechanisms
The BCM58100 Series Cryptographic Module includes the following physical security
mechanisms:
Broadcom Ltd. BCM58100B0 Series Cryptographic Module Security Policy Version 0.8 2016-05-25
Page 26
• Production-grade hard opaque tamper evident potting encapsulating material.
10. Mitigation of Other Attacks Policy
The module has not been designed to mitigate any specific attack beyond the requirements of
FIPS 140-2.
11. References
• National Institute of Standards and Technology, Digital Signature Standard (DSS),
Federal Information Processing Standards Publication 186-2, January 27, 2000 –
o http://csrc.nist.gov/publications/drafts.html
• National Institute of Standards and Technology, Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography, Special Publication
800-56A, March 2006.
o http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-56-A-1
12. Definitions and Acronyms
AES:
ECB, CBC,
CTR, CCM
Advanced Encryption Standard as defined by FIPS197 and SP800-38A to
SP800-38D
API Application Programming Interface
BIST Built-In Self Test
CSP A FIPS Critical Security Parameter
DLC Discrete Logarithm Cryptography
DSA Digital Signature Algorithm as defined by FIPS186-2
DRBG Deterministic Random Bit Generator
ECDH Elliptic-curve Diffie-Hellman algorithm
ECDSA Elliptic-curve Digital Signature Algorithm as defined by FIPS186-2
EMI/EMC Electromagnetic Interference/Electromagnetic Compatibility
FIPS Federal Information Processing Standard
FW Firmware
Broadcom Ltd. BCM58100B0 Series Cryptographic Module Security Policy Version 0.8 2016-05-25
Page 27
HMAC A keyed-Hash Message Authentication Code
HW Hardware
JTAG Joint Test Action Group – refer to the test interface standard as defined by
IEEE 1149.1 Standard
LPC Low Pin Count interface
OTP One Time Programmable memory.
RAM Random Access Memory
RFID Pseudorandom Number Generator
ROM Read Only Memory
RSA Rivest, Shamir, and Adleman algorithm for public key encryption
SBI Secure Boot Image. Authenticated software extension of the module’s BOOT
ROM (note: SBI software is part of the BCM5880 Cryptographic Module).
SCAPI Simple Cryptographic Application Programming Interface (refer to the crypto
library of BCM5880 firmware that utilizes the cryptographic hardware of the
BCM5880)
SHA Secure Hash Algorithm
SMAU Secure Memory Access Unit
SPI Synchronous Peripheral Interface
SRAM Static Random Access Memory
STS
TESTING
Statistical Testing
SW Software
TPM Trusted Platform Module
NDRNG Non-Deterministic Random Number Generator
UART Universal Asynchronous Receiver/Transmitter
USB Universal Serial Bus