Transcription
LifeSize Communications, Inc.Cryptographic Security KernelSoftware Version: 1.0FIPS 140-2 Non-Proprietary Security PolicyFIPS Security Level: 1Document Version: 1.0Prepared for:Prepared by:LifeSize Communications, Inc.901 S. Mopac Building 3 Suite 300Austin, Texas 78746U.S.A.Corsec Security, Inc.10340 Democracy Lane, Suite 201Fairfax, Virginia 22030U.S.A.Phone: 1 (512) 347-9300Fax: 1 (512) 347-9301http://www.lifesize.comPhone: 1 (703) 267-6050Email: info@corsec.comhttp://www.corsec.com
Security Policy, Version 1.0July 17, 2010Table of Contents1INTRODUCTION . 41.1 PURPOSE . 41.2 REFERENCES . 41.3 DOCUMENT ORGANIZATION . 42CRYPTOGRAPHIC SECURITY KERNEL . 52.1 OVERVIEW . 52.2 CRYPTOGRAPHIC BOUNDARY . 62.2.1 Physical Cryptographic Boundary . 62.2.2 Logical Cryptographic Boundary . 72.3 MODULE INTERFACES . 82.4 ROLES AND SERVICES . 92.4.1 Crypto-Officer Role . 92.4.2 User Role . 102.5 PHYSICAL SECURITY . 112.6 OPERATIONAL ENVIRONMENT . 112.7 CRYPTOGRAPHIC KEY MANAGEMENT . 112.7.1 Key Generation . 152.7.2 Key Entry and Output . 152.7.3 CSP Storage and Zeroization . 152.8 EMI/EMC . 152.9 SELF-TESTS . 152.10 DESIGN ASSURANCE . 162.11 MITIGATION OF OTHER ATTACKS . 163SECURE OPERATION . 173.1 INITIAL SETUP . 173.2 CRYPTO-OFFICER GUIDANCE . 173.2.1 Initialization . 173.2.2 Management. 183.3 USER GUIDANCE . 184ACRONYMS . 19Table of FiguresFIGURE 1 – LIFESIZE ROOM 200 (W/ CODEC, REMOTE, PHONE, AND CAMERA) . 5FIGURE 2 – LIFESIZE HOST SYSTEM BLOCK DIAGRAM . 7FIGURE 3 – LOGICAL BLOCK DIAGRAM AND CRYPTOGRAPHIC BOUNDARY . 8List of TablesTABLE 1 – FIPS 140-2 SECURITY LEVELS . 6TABLE 2 – FIPS INTERFACE MAPPINGS . 9TABLE 3 – MAPPING OF CRYPTO OFFICER ROLE’S SERVICES TO TYPE OF ACCESS . 9TABLE 4 – MAPPING OF USER ROLE’S SERVICES TO TYPE OF ACCESS .10TABLE 5 – FIPS-APPROVED ALGORITHM IMPLEMENTATIONS.12TABLE 6 – LIST OF CRYPTOGRAPHIC KEYS, CRYPTOGRAPHIC KEY COMPONENTS, AND CSPS .13LifeSize Communications, Inc. Cryptographic Security Kernel 2010 LifeSize Communications, Inc.This document may be freely reproduced and distributed whole and intact including this copyright notice.Page 2 of 21
Security Policy, Version 1.0July 17, 2010TABLE 7 – ACRONYMS .19LifeSize Communications, Inc. Cryptographic Security Kernel 2010 LifeSize Communications, Inc.This document may be freely reproduced and distributed whole and intact including this copyright notice.Page 3 of 21
Security Policy, Version 1.01July 17, 2010Introduction1.1 PurposeThis is a non-proprietary Cryptographic Module Security Policy for the Cryptographic Security Kernelfrom LifeSize Communications, Inc. This Security Policy describes how the Cryptographic SecurityKernel meets the security requirements of FIPS 140-2 and how to run the module in a secure FIPS 140-2mode. This policy was prepared as part of the Level 1 FIPS 140-2 validation of the module.FIPS 140-2 (Federal Information Processing Standards Publication 140-2 – Security Requirements forCryptographic Modules) details the U.S. and Canadian Government requirements for cryptographicmodules. More information about the FIPS 140-2 standard and validation program is available on theCryptographic Module Validation Program (CMVP) website, which is maintained by National Institute ofStandards and Technology (NIST) and Communication Security Establishment Canada The Cryptographic Security Kernel is referred to in this document as the cryptographic module, or themodule.1.2 ReferencesThis document deals only with operations and capabilities of the module in the technical terms of a FIPS140-2 cryptographic module security policy. More information is available on the module from thefollowing sources:The LifeSize website (http://www.lifesize.com) contains information on the full line of productsfrom LifeSize.The CMVP Vendor List 0-1/1401vend.htm)contains contact information for answers to technical or sales-related questions for the module.1.3 Document OrganizationThe Security Policy document is one document in a FIPS 140-2 Submission Package. In addition to thisdocument, the Submission Package contains:Vendor Evidence documentFinite State MachineSubmission SummaryOther supporting documentation and additional referencesThis Security Policy and the other validation submission documentation were produced by Corsec Security,Inc. under contract to LifeSize. With the exception of this Non-Proprietary Security Policy, the FIPS 140-2Validation Documentation is proprietary to LifeSize and is releasable only under appropriate nondisclosure agreements. For access to these documents, please contact LifeSize.LifeSize Communications, Inc. Cryptographic Security Kernel 2010 LifeSize Communications, Inc.This document may be freely reproduced and distributed whole and intact including this copyright notice.Page 4 of 21
Security Policy, Version 1.02July 17, 2010Cryptographic Security Kernel2.1 OverviewLifeSize Communications, Inc. is a high definition video and audio communication company that providesHigh Definition video endpoints, infrastructure and management solutions for all types of organizations.The LifeSize lines of video communications products provide affordable, full-motion video and audiotelepresence solutions for any size room. LifeSize sells a robust set of product lines. The LifeSize “Room”line consists of the Room, Room 200, and Room 220, and is designed to be deployed in medium-sizedconference rooms. The LifeSize “Team” line consists of the Team MP, Team 200, and the Team 220, andis designed to be deployed in small conference rooms or used by small groups of people. The LifeSize“Express” line consists of the Express, Express 200, and the Express 220, and is designed to be deployed atan individual’s desk for single-person use.The LifeSize products are actually systems consisting of several system components (see Figure 1 belowfor the components of the Room 200 product). At a minimum, the systems will include the followingcomponents:LifeSize coder/decoder device (codec)LifeSize high-definition pan-tilt-zoom cameraLifeSize phone or “MicPod”wireless remotepower supplycablesFigure 1 – LifeSize Room 200 (w/ codec, remote, phone, and camera)The LifeSize codecs perform the bulk of the audio and video processing, provide the primaryadministrative and user interfaces, and perform encryption and security functions. All of the LifeSizecodecs have a similar architecture (differing in licensed features and available physical ports), and all runthe same software image.Each LifeSize codec has multiple physical interfaces that allow it to be connected to audio/video sourcessuch as cameras, microphones, LifeSize phones, and Ethernet networks. The codecs also implementseveral management interfaces: an on-screen User Interface (UI) that is displayed on an attached monitorLifeSize Communications, Inc. Cryptographic Security Kernel 2010 LifeSize Communications, Inc.This document may be freely reproduced and distributed whole and intact including this copyright notice.Page 5 of 21
Security Policy, Version 1.0July 17, 2010and manipulated via an infrared remote control; a command-line interface (CLI) via SSH1 and a serial port;a web-based graphical user interface (GUI) via HTTP2 and HTTPS3, and an SNMP4 interface.Audio and video data is transported via the Session Initiation Protocol (SIP) or H.323 (an audio/videocommunications protocol for packet networks), and this data can be encrypted if both sides of thecommunication agree to use encryption. The codecs, utilizing security functions provided by LifeSize’sCryptographic Security Kernel, use the Advanced Encryption Standard (AES) algorithm to encrypt anddecrypt data.All of the products’ cryptographic functionality is provided by the Cryptographic Security Kernel, which iscomposed of functionality contained in a single object file. The cryptographic module runs on a Linux 2.4Operating System (OS), executed by a PowerPC processor, and does not modify or become part of the OSkernel.The Cryptographic Security Kernel is validated at the following FIPS 140-2 Section levels:Table 1 – FIPS 140-2 Security LevelsSectionSection TitleLevel1Cryptographic Module Specification12Cryptographic Module Ports and Interfaces13Roles, Services, and Authentication14Finite State Model15Physical Security6Operational Environment17Cryptographic Key Management15N/A8EMI/EMC19Self-tests110Design Assurance111Mitigation of Other AttacksN/A2.2 Cryptographic boundaryThe following sections will define the physical and logical boundary of the Cryptographic Security Kernel.2.2.1 Physical Cryptographic BoundaryAs a software cryptographic module there are no physical security mechanisms implemented per se, themodule must rely on the physical characteristics of the host system. The physical cryptographic boundaryof the Cryptographic Security Kernel is defined by the hard enclosure around the host system on which itruns. All physical ports are realized by the host system’s physical ports and may vary per platform. Figure1 below depicts the typical LifeSize hardware platform with accompanying physical ports, the dotted blue1SSH – Secure ShellHTTP – Hypertext Transfer Protocol3HTTPS – Secure Hypertext Transfer Protocol4SNMP – Simple Network Management Protocol5EMI/EMC – Electromagnetic Interference / Electromagnetic Compatibility2LifeSize Communications, Inc. Cryptographic Security Kernel 2010 LifeSize Communications, Inc.This document may be freely reproduced and distributed whole and intact including this copyright notice.Page 6 of 21
Security Policy, Version 1.0July 17, 2010line surrounding the module components represents the module’s physical cryptographic boundary, whilethe ports and interfaces exist at the boundary and interface with the various controllers.LifeSize Hardware Block DiagramVideo PortVideoInput/outputTelephone PortAnalogPhoneUSB portUSBDeviceSerial PortSerialdeviceVideo Encoder/DecoderFlashAnalogTelephoneControllerPPC basedHost ProcessorUSB ControllerSerial (RS-232)ControllerInfraredReceiverInfrared twork PortEthernetDisplay PortDisplay AdapterAudio Encoder/DecoderMonitorAudio PortAudioInput/OutputCryptographic BoundaryPlaintext dataEncrypted dataControl dataStatus dataCrypto boundaryKEY:PPC – Power Performance Computing (PowerPC)RAM – Random Access MemoryFigure 2 – LifeSize Host System Block Diagram2.2.2 Logical Cryptographic BoundaryFigure 3 below shows a logical block diagram of the module. The module is a software only cryptographicmodule running on a Linux operating system. The module’s logical cryptographic boundary encompassesall functionality contained within a single object file. This object file is linked at build-time to a sharedobject, which can be called by host applications to provide cryptographic services.LifeSize Communications, Inc. Cryptographic Security Kernel 2010 LifeSize Communications, Inc.This document may be freely reproduced and distributed whole and intact including this copyright notice.Page 7 of 21
Security Policy, Version 1.0July 17, 2010Primary StorageCPU loads OS, hostapplication, library intomemory when neededMemoryModule loadedat run-timelibcrypto.soCryptographicModuleHost ApplicationOS schedulesCPU time forhost applicationexecutionOperating SystemCPU runsmachine codePlaintext dataEncrypted dataControl inputStatus outputCrypto boundaryCPUFigure 3 – Logical Block Diagram and Cryptographic Boundary2.3 Module InterfacesThe module’s logical interfaces exist at a low level in the software as an Application ProgrammingInterface (API). The API interface is mapped to the following four logical interfaces:Data inputData outputControl inputStatus outputThe module features the physical ports of the host system, as depicted in Figure 2. The following is a listof physical interfaces implemented on a host system:Video portTelephone portUSB6 portSerial portInfrared port (Remote control)Network portDisplay portAudio portAC Power portAs a software module, the module has no physical characteristics. Thus, the module’s manual controls,physical indicators, and physical and electrical characteristics are those of the host system.The FIPS-defined interfaces map to their physical and logical counterparts as described in Table 2 below.6USB – Universal Serial BusLifeSize Communications, Inc. Cryptographic Security Kernel 2010 LifeSize Communications, Inc.This document may be freely reproduced and distributed whole and intact including this copyright notice.Page 8 of 21
Security Policy, Version 1.0July 17, 2010Table 2 – FIPS Interface MappingsFIPS 140-2 InterfacePhysical InterfaceModule Interface (API)Data InputVideo portTelephone portUSB portSerial portInfrared port (Remote control)Network portAudio portFunction calls that accept, as theirarguments, data to be used orprocessed by the moduleData OutputVideo portTelephone portUSB portSerial portNetwork portDisplay portAudio portArguments for a function that specifywhere the result of the function isstoredControl InputSerial portInfrared port (Remote control)Network portFunction calls utilized to initiate themodule and the function calls used tocontrol the operation of the module.Status OutputVideo portSerial portNetwork portDisplay portAudio portReturn values for function callsPower InputAC power portN/A2.4 Roles and ServicesWhile the module itself provides no mechanism for the authentication of operators, it supports thefollowing authorized roles: the Crypto-Officer (CO) role and the User role.Note: The following definitions are used in the “CSP and Type of Access” column in Table 3 and Table 4.Read - The item is read or referenced by the service.Write - The item is written or updated by the service.Execute - The item is executed by the service. (The item is used as part of a cryptographic function.)2.4.1 Crypto-Officer RoleThe Crypto-Officer role is used for initializing the module and for accessing the module’ssymmetric/asymmetric encryption/decryption, signature generation/verification, hashing, cryptographic keygeneration, random number generation, and message authentication functions.Descriptions of the services available to the Crypto-Officer role are provided in Table 3 below.Table 3 – Mapping of Crypto Officer Role’s Services to Type of AccessServiceInstallationDescriptionInstallation of the moduleCSP and Type of AccessNoneLifeSize Communications, Inc. Cryptographic Security Kernel 2010 LifeSize Communications, Inc.This document may be freely reproduced and distributed whole and intact including this copyright notice.Page 9 of 21
Security Policy, Version 1.0ServiceInitializationJuly 17, 2010DescriptionCSP and Type of AccessPerform module initializationNoneHashing (SHA )Perform hashing operationNoneMessage Authentication(HMAC8)Perform message authentication HMAC SHA-1 key – rm encryption/decryptionoperationAES9 symmetric key – ExecuteTDES10 symmetric key – ExecuteDigital SignaturePerform sign and verifyoperationDSA11 private key – ExecuteRSA12 private key – ExecuteKey EstablishmentKey establishment-supportingmechanism (Diffie-Hellman,RSA)RSA private key – ExecuteDiffie-Hellman private key – ExecuteSymmetric Key GenerationGenerate symmetric keysAES Symmetric key – ExecuteTDES Symmetric key – ExecuteAsymmetric Key GenerationGenerate asymmetric keysDSA private key – ExecuteRSA private key – ExecutePseudo-Random NumberGenerationGenerate random numbersSeed key – ExecuteSeed – ExecuteShow StatusShow status of the moduleNonePerform Self-TestsPerform self-tests on demandNoneZeroizationZeroize all CSPsAES Symmetric key – WriteTDES Symmetric key – WriteDSA private key – WriteRSA private key – WriteDiffie-Hellman private key – WriteHMAC SHA-1 key – WriteSeed key – Write72.4.2 User RoleLike the CO role, the User roles is used to access symmetric/asymmetric encrypt
The LifeSize “Team” line consists of the Team MP, Team 200, and the Team 220, and is designed to be deployed in small conference rooms or used by small groups of people. The LifeSize “Express” line consists of the Express, Express 200
