1 / 17

FIPS 140 Validation for a “System-on-a-Chip”

FIPS 140 Validation for a “System-on-a-Chip”. September 27, 2005 NIST Physical Testing Workshop. Presenters. Richard Goble Security Software Architect Britestream Networks, Inc. Richard_Goble@Britestream.com Chris Brych FIPS 140 Program Manager

powelle
Download Presentation

FIPS 140 Validation for a “System-on-a-Chip”

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. Presenters Richard Goble Security Software Architect Britestream Networks, Inc. Richard_Goble@Britestream.com Chris Brych FIPS 140 Program Manager DOMUS IT Security Laboratory cbrych@ca.ibm.com

  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

  5. Level 3 Symmetric Level 1 Asymmetric Policy Mgmt What is a Secure System? • 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

  6. Increasing Security Security Level 4 Security Level 3 Security Level 2 Security Level 1 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…

  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 140-2 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

  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

  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

  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

  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

  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.

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

More Related