1. FIPS 140 Validation for a “System-on-a-Chip”
September 27, 2005
NIST Physical Testing Workshop

2. Security Software Architect Britestream Networks, Inc.
Presenters
Richard Goble
Security Software Architect
Britestream Networks, Inc.
Chris Brych
FIPS 140 Program Manager
DOMUS IT Security Laboratory

3. Objectives Britestream FIPS Solution: BN1250 Secure NIC
What is a Secure System?
How Strong do the Defenses need to Be?
Effects of Moore’s Law on Systems
Boundaries Moving inside the SoC
How To Test to FIPS 140
Testing a SoC Cryptographic Module Challenges
Testing From a Britestream’s Perspective

4. Britestream FIPS Solution: BN1250 Secure NIC
PCI-based Gigabit Ethernet Secure NIC card
Uses the BN2010 ASIC (A network security System-on-a-Chip (SoC))
Supports several protocols (i.e. Ethernet, TCP/IP, TLS)
Provide asymmetric and symmetric cryptographic operations in hardware
Extensively tested to assure that the protocols and cryptography are correct and interoperable
Provides true 100% SSL/TLS Offload
Secure asymmetric private keys
FIPS Tested, Tamper-resistant Hardware
DOMUS IT Security Laboratory, IBM Canada
Verified the BN1250’s cryptography and boundaries conforms to FIPS 140-2
Protocols: Ethernet, IP, TCP, TLS which contains asymmetric and symmetric encryption

5. What is a Secure System? Level 3
A system a group of inter-related yet independent functions, each with an identifiable boundary, that comprise a unified technology solution
Appropriate cryptographic functions are designed and implemented in order to secure critical areas of the system
A cryptographic boundary is the logical grouping of the cryptographic functions within the system
Level 3
Asymmetric
Symmetric
Level 1
Policy Mgmt

6. How Strong do the Defenses need to Be?
All cryptographic boundaries in the system are needed
Some are important…
Others are critical…
Each boundary should be evaluated based on its needs
Some need to be secured…
Some don’t…
Security Level 4
Security Level 3
Security Level 2
Security Level 1
Increasing Security
Image Source:
Protocols: Ethernet, IP, TCP, TLS which contains asymmetric and symmetric encryption

7. Effects of Moore’s Law on Systems
Today our system can be implemented and validated within any of these environments

8. Effects of Moore’s Law on Systems
Today our system can be implemented and validated within any of these environments
Emerging SoC solutions create the need to also validate secure crypto boundaries within a micro-environment

9. Boundaries Moving Inside the SoC
A system will always have the same FIPS requirements however the development and testing techniques will vary based on the implementation environment
The current FIPS standard validates logical boundaries down to the size of a single chip, but it does not contain a definition of a sub-chip boundary, or SoC micro- boundary
In the SoC, all trusted paths, between any of the boundaries or external interfaces, must remain valid and intact
So how do you ensure that the micro-boundary is secure?

10. FIPS 140 Testing How are Current Environments Tested?
Multi Chip Standalone
Multi-Chip Embedded
Single Chip
Scope of FIPS Testing
Verifying Algorithms and RNG are Implemented Correctly
Verifying the Design of the Functional Spec
Defining the Cryptographic Boundary
Verifying the Ports and Interfaces
Verifying the Roles, Services and Authentication
Define the Cryptographic Boundary
Verify the algorithms
Define and verify ports and interfaces (monitor data input and output through these ports) Tools to use include packet sniffers, logic analyzers, port sniffers etc. Verify that data is not output while in a Self-Test State and Error State
Verify roles, services, and authentication mechanisms. This involves exercising the cryptographic module to verify the roles and services described in the non-proprietary security policy. Verify the authentication mechanisms claimed by the vendor whether it be password based or certificate based.

11. FIPS 140 Testing Scope of FIPS Testing
Verifying the Finite State Model
Physical Testing
Verifying the Key Management Properties
EMC/EMI Testing
Verifying the Self-Tests
Verifying the Configuration Management and Design Processes
Verifying the Cryptographic Module Security Policy
Verifying the Finite State Model
Testing the Physical Security properties of a cryptographic module
Verifying the key management properties of the cryptographic module including key Generation, key input/output, key storage, key zeroization
EMI/EMC Testing
Verifying the implementation of Self-Tests
Verifying the configuration management and design processes of the cryptographic module
Verifying the Cryptographic Module Security Policy

12. FIPS Testing of a SoC Module
Define the Cryptographic Boundaries in Hardware
Treat Each Boundary as a Separate Certification
Test the FIPS Approved Algorithms and RNG
Identify the Interfaces into and out of the Cryptographic Boundaries
Verify the Data Flow Types Within the Cryptographic Boundaries
Verify the Roles, Services, and Authentication Mechanisms
Verify the Finite State Machine Transitions
Define a logical cryptographic boundary within the physical perimeter of the chip
Validate each boundary as a separate certification
Test the FIPS Approved Algorithms through CAVS testing
Identify the interfaces into the cryptographic boundary (This can be accomplished through analysis of block diagrams of the cryptographic module.
The data flows within the cryptographic boundary must also be verified. This must also be supported by an architecture schematic that shows the types of data flows within the cryptographic boundary. This must include what is considered plaintext or encrypted data, command inputs, status outputs. The challenge with verifying the ports and interfaces of a system-on-chip design is that you cannot use the same tools to verify data flows that we currently use to test cryptographic modules because once the chip has gone to fabrication, there is no way to monitor the interfaces within the chips cryptographic boundary. The tester can monitor interfaces pins into and out of the chip.
Verify the Roles, Services, and authentication mechanisms of the cryptographic module
Verify the Finite State Machine transitions by exercising the module to verify its states and that the module operates correctly in its States.

13. Testing of a SoC Module Physical Testing of the Chip
Use of Flip Chip process of Protecting the System
Test the Key Management Properties
Verify No Access to Keys to Modify Them
Monitor Keys Input and Output from the Physical Chip to insure that they are encrypted
Code Review of Deterministic RNG
Verify Key Destruction Mechanisms
Verify Chip Meets EMC/EMI Requirements
Verify the chip has a FCC conformance report
Test the chip to verify that the coating on the chip cannot be removed to expose the internals of the chip. The most common protection mechanism for a chip is a process called “Flip Chip” which coats the chip in an epoxy resin to protect the internals of the chip, much the same as epoxy resin protects a multi-chip embedded cryptographic module.
Testing the key management properties of a system on chip design is difficult as it implies that the operator can access the keys stored within the cryptographic boundary.

14. Testing of a SoC Module Verify Self-Tests are implemented
Code Review Self-Tests and
Induced Failures of Algorithm and RNG Self-Tests
Induced Failure of Firmware Integrity Test
Induced Failure of Firmware Update Verification Test
Code Review of Pairwise Consistency Tests
Code Review of Bypass Test
Verification of Configuration Management System and Configuration Items
Verify that Self-Tests are implemented by inspection of source code
Perform functional testing to fail all of the algorithm self-tests to insure that the module transitions into an error state
Verify the integrity test failure if firmware image is modified
Verify firmware load testing failures by trying to load a bad firmware image.
Code review of pairwise consistency tests
Code review of bypass tests
Verify a configuration management system and configuration items

15. Challenge in Testing of a SoC
The Major Challenge in Testing a SoC Module is Verifying and Testing the Interfaces.
Since the modules logical boundary is defined within the confines of a chip that is coated in epoxy resin, it is not possible to probe the network phy’s to monitor traffic coming into and out of the cryptographic boundary. Have to rely on vendor testing and design schematics to verify the interfaces into and out of the cryptographic boundary. Richard will now discuss some of Britestreams testing methods .

16. Britestream Testing of a SoC Module
A Silicon Team’s Survival Depends on not Producing a “brick”
Thorough Upfront Development
Architecture
Design
Test and validation plans
Pre-validation with FIPS Lab
Unit Level Test via RTL Simulation
Cover well know vectors, corner cases, exceptions cases, randomization of parameters, varying data lengths, etc.
Verify that the interfaces to boundaries operate correctly and CSPs are handled properly
System Test Via RTL FPGA Simulation Boards
Generate a matrix of ciphers, versions, key sizes
Test the matrix against a variety of platforms and different external algorithm implementations.
Boundary behavior can be monitored with logic analyzers.
Incorporate Quality Code control and bug tracking
Insure that regression testing incorporates bug stimulus.
Silicon teams can’t lose the time or money to get back any form of a “brick” from manufacturing.
Upfront design work is probably more important then the physical implementation of the product.
Simulation is an effective test tool to test near speed functionality. Simulations can’t execute thousands of functional iterations.
Simulation builds can bring out boundary signals to a monitor port. Logic analyzers can be triggered on success or failure cases at these monitors.

17. Open Forum
What Other Considerations or Tests Must be Performed in Order to Validate a System Within a Chip?