1 A Key Management Architecture for Digital Cinema Sebastian Knop 1, Jan Fröhlich 1, Roland Schmitz 2 1 CinePostProduction GmbH, Munich, Germany 2 Hochschule der Medien, Stuttgart, Germany 1 Introduction The advent of digital cinema technology called for the creation of open standards to ensure high technical performance, reliability and interoperability of these systems. This call was answered by the Digital Cinema System Specification , which was first published in July 2005 by the Digital Cinema Initiatives LLC, a jointventure of the motion picture studios Disney, Fox, Metro-Goldwyn-Mayer1, Paramount Pictures, Sony Pictures Entertainment, Universal Studios and Warner Bros. Studios. The specification regulates formats, interfaces, equipment behavior and testing procedures, affecting every stage from the creation of the final content distribution package at a production studio to the actual exhibition at a theater. It has since become the de-facto standard for the rapidly growing number of installed digital cinema systems. Content protection is provided by a digital rights management (DRM) system described in the specification, making use of asymmetric key cryptography and digital certificates. The renting of analog film reels is emulated by content decryption keys with limited validity periods. Thus, the generation and management of those keys becomes part of the service that has to be offered by content providers, production studios or distributors. Compared to the development in the USA or UK, the adoption of digital cinema technology by theaters in Germany has been slower. Nevertheless, the numbers are increasing fast. From the total of approximately 4800 screens in Germany , 164 screens were equipped with digital projection technology in June 2008 . By December 2009, an approximate total of 350 screens had already been switched , and by October 2010 the estimated amount grew over 800 screens. In this context, the post-production studio CinePostproduction GmbH wanted to expand its service portfolio to include the generation of DCI compliant keys. For the successful integration of such a facility into the production workflow and to attend to the business requirements, a key management architecture is required. 2 DCI Security Architecture The security architecture described in the DCI specification pursues a number of high level goals: Enable decryption and playback of content based on a set of rules agreed upon by the involved business entities, protect content against unauthorized access, copying, editing and playback, keep records of security related events, define the security architecture in an open fashion and provide a set of standards allowing the implementation of compliant equipment by third parties. The stated goals are achieved primarily through the use of content encryption and a digital rights management system focused on the exhibition environment. To enable the decryption and playback of content according to the defined rules in such a system, decryption keys and further data must be transported from content provider to the exhibitor in a secure way. For the transport of keys and the DRM related data, the specification defines the Key
2 Delivery Message (KDM) format (see section 2.4). Each KDM has a specific validity period, the time span during which a Security Manager (see section 2.2) will authorize the decryption and playback of the associated content 2.1 Protecting Track Files and Reels The DCI packaging (DCP) format is based on a hierarchical system. The smallest units in this system are track files, carrying a single essence of actual content like image, audio or subtitle data, plus metadata. A compliant track file is a self-contained instance that can be interpreted by a compliant decoder. A track file starts with a file header and ends with a file footer. The track file body consists of several KLV (key length value) units. The key is an identifier for the content type of the KLV unit, length specifies the length of the value. When encryption is used to protect the content, only the essence is encrypted, but the original KLV triplet is embedded into a new KLV with adapted metadata, additional encryption data and the message integrity code (MIC), which allows every frame to be checked for consistency. The DCI specification defines JPEG2000  as an intra-frame codec. Although there is a standard called JPSEC  covering JPEG2000 compliant encryption, the DCI specification uses a different approach: Encryption is performed on the essence KLV packets covering one frame (or data with the duration of a frame) each, using the AES block cipher algorithm in cipher block chaining (CBC) mode with a 128 bit key, as defined by NIST in . At the next level in the package hierarchy are reels. The reel concept originates from the physical reels of analogue film typically covering 10 to 20 minutes of play time, but it was carried over into the digital workflow as a means of segmenting a feature film into multiple parts for easier handling during post production. A reel is required to consist of at least one track file. Playback devices are required to be able to play back content segmented into reels without artefacts and without interruptions on reel boundaries. When encryption is used, one key per reel and per track file shall be used. 2.2 Playback Environment In the playback environment, the functional entity that processes the keys and that is trusted to enforce the rules of the DRM system is the Security Manager (SM). It is a logically separate component of the architecture, although it is intended to be implemented as part of the playback server. SMs and other security critical components, called security entities (SE), are placed inside a Secure Processing Block, which provides physical security to the relevant hardware. Figure 1: Digital Cinema auditorium security components Figure 1 shows a schematic overview of the security components of a theater auditorium. The basic functions of the shown components are as follows:
3 The Image Media Block (IMB) is a Secure Processing Block (SPB) which shall contain a Security Manager, Media Decryptor (MD), Forensic Marker (FM), and a Link Encryptor (LE) module. The Projection System is a Secure Processing Block (SPB) containing a Link Decryptor (LD), an optional Forensic Marker and the actual optical image generation system. Image Media Block and Projection System may be implemented in an integrated fashion (not shown in the figure); in that case the LE and LD are omitted. SPB1 and SPB2 denote two physical protection levels for Secure Processing Blocks, where SPB1 offers a higher level of physical security than SPB2. The Security Manager (SM) is the security entity trusted to enforce the rules of the DRM system and provides the decryption of the content decryption keys as well as authentication and control over secure processing blocks. The Media Decryptor (MD) is the component responsible for decrypting the encrypted content with the content decryption keys. The Forensic Marker (FM) is responsible for embedding a digital watermark into both image and video. If the Image Media Block contains a FM, the FM in the Projection System is optional. The Link Encryptor (LE) and the Link Decryptor (LD) are the modules responsible for encrypting and decrypting the content for transport outside of SPBs over a wired connection. The Extra Theater Message (ETM) and the Intra Theater Message (ITM) are generic formats for security related messages The Secure Processing Block (SPB) The SPB is a generic container with a defined perimeter providing physical protection for security critical system components such as trusted entities like the Security Manager or modules handling content in plaintext form. This is intended to offer protection to secrets not secured by cryptographic mechanisms. SPBs shall carry an RSA private key  and a matching digital certificate stating their role, as to allow authentication by a Security Manager or another SPB. After physical installation, equipment with interacting SPBs needs to undergo a process called marrying, in which the SPBs mutually exchange and store their certificates after a human supervisor confirmed a correct interconnection of the systems, which is a prerequisite for a secure TLS connection with mutual authentication between SPBs. According to the DCI specification, SPBs shall have the following characteristics: Tamper evident: Breaches of the security perimeter shall permanently alter the equipment, which should be noticeable upon inspection. Tamper resistant: Breaching the security perimeter to expose the contained secret shall be difficult and require considerable effort and tools. Tamper detecting and responsive: The security perimeter is actively monitored, triggering the erasure of the protected secrets in case of a breach Link Encryption Link encryption shall be used in all cases where plaintext content is exchanged between SPBs. In this case, the Image Media Block (IMB) shall provide the Link Encryption keys to be used, to both the Link Encryptor and Link Decryptor. The specification requires the use of either Triple DES with 112 bit keys , or AES with 128 bit keys. For each transfer of encrypted content, a new set of encryption keys is mandatory.
4 2.2.3 Forensic Marking The specification requires that each IMB shall be equipped with a forensic marking module. Watermarking does not prevent unauthorized copying or playback of content. However, it allows for tracing leaked content back to the installation which performed the original playback, helping in taking measures to prevent future leaks . The DCI does, however, not define the use of a specific watermarking technology, rather formulating a list of requirements and leaving the implementation up to the equipment manufacturers. The list of requirements includes the following points: The watermarking technology shall allow the embedding of at least 35 bits of data. Of these, 16 bits are used for a timestamp with 15 minute granularity, covering the span of one year before repeating. The remaining 19 bits are used to code a serial number, which shall uniquely identify the FM module and thus the playback system used. The 35 bits of data shall be embedded in every 5 minute segment of the playback. Each Forensic Marker instance shall be assigned a unique serial number (FMID), which cannot be reprogrammed without breaching the security perimeter provided by the type 1 SPBs. Providers of watermarking technology shall offer it under reasonable and non-discriminatory (RAND) terms. Detection shall be possible within the premises of the rights owner. The watermark shall be robust enough to survive a number of signal processing attacks, image/audio transformations, format conversions and recording by consumer electronics. There is a number of suitable video watermarking methods available (see e.g. ). 2.3 X.509 Digital Certificates Digital certificates are a cornerstone of the DCI security architecture. They enable a series of security functions like encryption, digital signatures, authentication and the implicit transfer of trust. At the core of the certificate concept is the RSA key pair. This pair of keys enables the elementary asymmetric key cryptography functions, specifically encryption with the public key, decryption with the private key and signing with the private key, verifying with the public key. The DCI architecture makes use of digital certificates in the X.509 version 3 format , with a clearly defined set of characteristics. For example, it is specified that the RSA public key modulus shall have a length of 2048 bits. The employed signature algorithm shall be SHA-256  with RSA key encryption. The concept of using trusted third parties to sign certificates enabling the transfer of trust can be extended to a scenario, where whole chains of certificate signing are used. They form a tree-like structure, where all certificates are directly or indirectly derived from one single certificate, the root of trust. In this context, the entity controlling the signing certificate is called Certificate Authority (CA). The certificate at the top of the signing tree has to be self-signed and is called the Root CA certificate. Certificates that sign other certificates, but are not self-signed, are called Intermediate CA certificates. Finally, the certificates at the edge of the tree, that do not sign any other certificates, are called Leaf certificates. If implemented consistently, the number of certificates, that other entities have to know as trusted in order to be able to verify other incoming certificates, can be reduced to one, or few, depending on how many certificate trees are being used. The signature of a received certificate is verified, and then the signature of the signing certificate is verified. This is repeated recursively until the root certificate is reached, confirming the authenticity of the whole chain. The specification requires that the employed certificate chains have a length of at least two beyond the leaf certificate, meaning at least one intermediate certificate between root and leaf. For the verification of certificate chains, the specification cites numerous properties to be checked. For instance, the verification of the validity shall be performed in the chain context, where the validity of the signed certificate must fit completely into the
5 period of the signing certificate. Signing is only allowed by certificates that carry the appropriate flags and role specifications. 2.4 Key Delivery Message (KDM) The KDM is a specialized instance of an ETM used to transport content decryption keys and DRM information to a SM. KDMs are always targeted at a specific recipient. This is achieved by means of encryption using the public key of the recipient s certificate. This way, the content decryption keys are protected and only the holder of the matching private key is able to extract them from the KDM. 3 The Key Management Architecture Project 3.1 Requirements The existing workflow for KDM ordering at CinePostproduction GmbH, henceforth referred to as CPP, can be described as follows: When an employee of a movie theater orders a DCP and KDMs for his theater server(s) from his distributor, the distributor in turn sends an order to CPP s distributor scheduling office by fax or , where it is entered into an ERP system. The order is accompanied by a digital certificate file from the theater server(s) for which the KDM(s) should be generated. For the creation of DCPs, CPP employs a mastering system being able to encode and package audiovisual content into distribution-ready DCPs. Additionally, a limited number of KDMs, also known as distribution KDMs or master KDMs, are generated, to be used for deriving the KDMs for the actual playback on the theater servers. In the past, however, CPP lacked a suitable system for KDM creation and had to rely on a third party to generate them. Therefore, a project was initiated with the following requirements: A system for the generation of DCI compliant keys (KDMs) shall be implemented, along with an architecture for the management of keys and digital certificates, which is to be integrated into the existing workflow of the company. A security concept to protect the sensitive data contained in the systems shall be designed, while minimizing its operational impact on the usability. The implementation should build on open source software and other freely available core technologies. 3.2 Design The key management architecture project was christened CinDi, as an acronym composed of the initials of cine, digital and distribution. The design followed the idea of using an existing web platform developed in-house, which is currently used to deliver movie trailer DCPs to theaters, as well as for providing video samples of post production work to customers, as a platform for the management of KDMs. For security reasons, the process of generating the KDMs should be separated from it. This way, the web platform could be extended to provide the user interface and all the necessary key and order management features, while the actual KDM generation and security critical processes are performed with a separate software component running on another, protected system. For the communication between systems, an interface based on HTTP and XML was designed. The system hosting the KDM generator is protected by an additional firewall. This firewall between the KDM generator and the web platform is configured to allow only allow traffic between them and only outgoing HTTPS connections from CinDi, blocking all other forms of traffic and traffic origins. Once implemented and integrated into CPPs workflow, CinDi will change the existing ordering process, as described in section 3.1, to a new process (see Figure 2) differing from the existing one the following points: When DCPs are created, the CPLs and master KDMs generated along with them are imported in the web platform.
6 After the distributor scheduling office receives an order for a KDM, the relevant order details are entered in the web platform, together with the target certificate. The KDM generator picks up the order package, generates the KDM(s), and posts them back to the web platform in a delivery package. The web platform sends the KDMs to the specified recipients via . CinePostproduction Distributor Order + Certificate Distributor Scheduling Assignment Digital Lab Mastering System Order + Certificate Certificate Master KDM Theater Player DCP KDM Web Platform Order Delivery CinDi KDM generator The KDM Generator Figure 2: The Workflow for Generating KDMs The KDM generator is the key component of the CinDi architecture. It takes a master KDM, a target player certificate and an order description as input and generates a KDM for the referred target player as output. The architecture was designed in such a way that the existing web platform handles all data persistency and user interactions. The KDM generator does not store output except for log entries; all relevant output files and messages are sent back to the web platform. Except for the initial configuration, the only duty that needs to be performed by a user on the KDM generator is managing the set of trusted CA certificate chain files. The intent of this design is to allow the KDM generator to run mostly autarkic and isolated for security reasons, requiring as little as possible user intervention. The KDM generator contains private keys that enable the decryption of the content decryption keys in the master KDM, and should therefore be protected from access. By reducing the complexity of the KDM generator software, the potential for security flaws is reduced. On the Linux based host system, the Cron scheduler daemon or comparable mechanism is configured to initiate a script of the KDM generator in regular intervals. Once activated, the script polls the web platform for new order packages. If new orders are available, an order description is created and returned to the KDM generator. If the manual mode of operation of the KDM generator is being used, order packages may be processed, being supplied over the local web interface or copied to the local file system and given as parameter on the execution via CLI. The received order package is processed by the KDM generator. This includes the validation and signature verification of the order description. The target player certificate sent with each individual KDM order is validated against the procedures of the CTP, and then verified against the set of trusted certificate chains. Having passed those tests, the order is dispatched to the KDM engine, which generates a new KDM based on the provided master KDM, the order description and the target player certificate. Once all orders have been processed, a delivery package with description and signature files are generated posted back to CPPs web platform.
7 3.2.2 Realization The main programming task in the CinDi project was the implementation of the KDM generator. The very first steps taken in the implementation were some experiments done to determine if PHP would be adequate as a programming language. Python and Java were also briefly considered, but PHP was the first choice for a number of reasons: The web platform is already written in PHP and since it will interface with the KDM generator, some code reuse was expected to be possible. The most critical feature set that had to be investigated were the available cryptographic functions and the capabilities for handling X.509 digital certificates. Upon investigation it was determined, that the Hash and the OpenSSL extensions combined would cover all necessary elementary cryptographic functions like the creation of hashes (SHA-1 and SHA-256), encryption and decryption with both symmetric (AES 128 bit) and asymmetric (RSA 2048 bit) keys, and the generation of pseudo-random numbers. Improvements and additions to these functions made PHP version the minimum requirement for CinDi. The handling of digital certificates is also enabled by the OpenSSL  extension, but it proved to be incomplete compared to the feature set of the command line version of OpenSSL or even the functions exposed in the API of the OpenSSL cryptographic library. For instance, when reading certificates, not all necessary information can be obtained with the PHP extension. When creating certificates, the extension only offers rudimentary controls over the characteristics of the created certificate. Another required but unavailable function is the extraction of specific sub strings of the binary representation of the digital certificate, including the segment holding the public key, or the to-be-signed portion of the certificate. It was determined, however, that it would be possible to implement unavailable functionality. With this assessment the choice for PHP as programming language for CinDi was confirmed. 4 Open Issues in the DCI architecture Originally the DCI consortium intended to implement a central CA for certificate signing and tie the distribution of certificates to third parties to successful standard compliance certification of the target devices. That way all certificates could easily be verified against a single trusted CA certificate and it would insure that only compliant devices would be allowed and thus utilized under the DCI label. However, because of monopoly concerns, political disagreement between the members of the consortium and in favor of adoption rate, this intended design was never put into practice, leaving the specification in a state where multiple CAs are allowed and where any CA is trusted by default. This has led to a number of issues. Most equipment manufacturers now act as their own CA, and since certification became optional, the requirements for standard compliance became less strict. In fact, equipment manufacturers defined an informal interim standard called Interop with a feature subset of the DCI and image storage based on MPEG2 instead of JPEG2000, to be used while DCI compliant equipment is being developed. As of this writing, only some projectors have been certified DCI compliant , while the first compliant Media Block is expected to be certified this year. DCI is not a registered trademark, so DCI capable equipment has been sold on the market before regardless. For content mastering studios or entities creating KDMs this means added complexity for the verification of target theater certificates, which is essential to prevent the supplying of content decryption keys to entities with a faked identity. Since no central CA exists, studios have to maintain their own pool of trusted CAs and implicitly trust the equipment manufacturers and their equipment without being able to rely on a certification asserting their security. Since CAs are trusted by default, a hypothetical attacker could forge a player certificate and certificate chain and send them both to a KDM creating entity (like is common practice during legitimate KDM ordering). Without proper trust verification against the set of known and trusted CA certificates it might wrongly create the requested KDM, thus compromising the content in the underlying DCP. It also enables another scenario, where a rogue content supplier distributes KDMs and/or DCPs after having gained access to the content by other means, since theater servers wouldn t reject those.
8 While the specification is now being standardized by standardization bodies like ISO, unfortunately the standard development efforts have mostly stopped, only adding special case support like stereoscopic images and other frame rates for archive footage. This essentially leaves the security of the DCI architecture in an inconsistent state, where content suppliers are left to deal with the resulting issues. 5 Conclusion In the present contribution, we have given an overview of the DCI security specification and we have described an approach to integrate the generation of DCI compliant Key Delivery Messages (KDMs) into the workflow at CinePostProduction GmbH. Some open issues concerning management of certificates, especially the default trust placed in CA certificates, were discussed, leading to the possibility of certificate chain forging and a rogue content supplier scenario. Since it is expected that the DCI specification will not be updated to rectify the issues with lacking mandatory certification, central CA and improper certificate trust verification, content providers have to develop methods for ensuring content security. An approach that is being considered to achieve that is a trusted device list (as certificate white and black list), either held by a neutral entity or shared among studios. References  Digital Cinema Initiatives, LLC. Digital Cinema System Specification, Version 1.2. Digital Cinema Initiatives.  Deutsche Filmförderungsanstalt. Marktdaten - Kinosaalbestand 2005 bis  European Audiovisual Observatory. Focus World Film Market Trends. European Audiovisual Observatory.  CineMedia Film AG. Geschäftsbericht  ISO/IEC. ISO/IEC Information technology - JPEG 2000 image coding system  ISO/IEC Information technology JPEG2000 imagecoding system, Part 8: Secure JPEG  National Institute of Standards and Technology (NIST), Special Publication A  R. Rivest, A. Shamir, L. Adleman: A method for obtaining digital signatures and public-key cryptosystems, Communications of the ACM, Vol. 21(2), p , 1978  National Institute of Standards and Technology (NIST), Federal Information Processing Standards (FIPS) Publication 56-3,  I. J. Cox, M. L. Miller, J. A. Bloom: Digital Watermarking, Morgan Kaufman Publishers, 2001  J. Lubin, J.A. Bloom, H. Cheng: Robust, Content Dependent, High Fidelity Watermark for Tracking in Digital Cinema, in: P. W. Wong, E. J. Delp (Eds.): Security and Watermarking of Multimedia Contents V, Proc. SPIE Vol. 5020, 2003  D. Cooper et al: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, IETF Proposed Internet Standard,  National Institute of Standards and Technology (NIST), Federal Information Processing Standards (FIPS) Publication 180-2,   Digital Cinema Initiatives, LLC. Compliance Test Plan Compliant Equipment
Secure Network Communications FIPS 140 2 Non Proprietary Security Policy 21 June 2010 Table of Contents Introduction Module Specification Ports and Interfaces Approved Algorithms Test Environment Roles
USING ENCRYPTION TO PROTECT SENSITIVE INFORMATION Commonwealth Office of Technology Security Month Seminars Alternate Title? Boy, am I surprised. The Entrust guy who has mentioned PKI during every Security
CHAPTER 1 Note The information in this chapter applies to both the ACE module and the ACE appliance unless otherwise noted. The features in this chapter apply to IPv4 and IPv6 unless otherwise noted. Secure
Page 1 of 7 White Paper on DCP What is a Digital Cinema Package (DCP)? A: Simply put, a DCP is the digital equivalent of a 35mm film print. It is what you give to a commercial theatre so they can screen
Digital Cinema Technologies from the Archive s Perspective by Arne Nowak, Dep. Moving Picture Technologies 1 Fraunhofer Institute for Integrated Circuits, Germany This is a revised version of an article
OFFICE OF THE CONTROLLER OF CERTIFICATION AUTHORITIES TECHNICAL REQUIREMENTS FOR AUDIT OF CERTIFICATION AUTHORITIES Table of contents 1.0 SOFTWARE 1 2.0 HARDWARE 2 3.0 TECHNICAL COMPONENTS 2 3.1 KEY MANAGEMENT
Accellion Secure File Transfer Cryptographic Module Security Policy Document Version 1.0 Accellion, Inc. December 24, 2009 Copyright Accellion, Inc. 2009. May be reproduced only in its original entirety
SMPTE Standards Transition Issues for NIST/FIPS Requirements v1.1 Contents 2010.8.23 DRM inside, Taehyun Kim ETRI, Kisoon Yoon 1 Introduction NIST (National Institute of Standards and Technology) published
MovieLabs Specification for Enhanced Content Protection Version 1.0 Introduction Digital content distribution technologies are evolving and advancing at a rapid pace. Content creators are using these technologies
Presentation This module contains all the SSL definitions. See also the SSL Security Guidance Introduction The package SSL is a static library which implements an API to use the dynamic SSL library. It
DVS DCI Signing Tool User Guide (Version 1.0) DVS DCI Signing Tool User Guide User Guide Version 1.0 for the DVS DCI Signing Tool Version 1.0 Copyright 2008 by DVS Digital Video Systems AG, Hanover. All
(KMIP) Addressing the Need for Standardization in Enterprise Key Management Version 1.0, May 20, 2009 Copyright 2009 by the Organization for the Advancement of Structured Information Standards (OASIS).
Lukasz Pater CMMS Administrator and Developer EDMS 1373428 Agenda Introduction Why do we need asymmetric ciphers? One-way functions RSA Cipher Message Integrity Examples Secure Socket Layer Single Sign
Chapter 11 Security+ Guide to Network Security Fundamentals, Third Edition Basic Cryptography What Is Steganography? Steganography Process of hiding the existence of the data within another file Example:
Digital Certificates (Public Key Infrastructure) Reshma Afshar Indiana State University October 2015 1 List of Figures Contents 1 Introduction 1 2 History 2 3 Public Key Infrastructure (PKI) 3 3.1 Certificate
CHAPTER 1 Secure Sockets Layer (SSL) is an application-layer protocol that provides encryption technology for the Internet. SSL ensures the secure transmission of data between a client and a server through
Using BroadSAFE TM Technology 07/18/05 Layers of a Security System Security System Data Encryption Key Negotiation Authentication Identity Root Key Once root is compromised, all subsequent layers of security
Complying with PCI Data Security Solution BRIEF Retailers, financial institutions, data processors, and any other vendors that manage credit card holder data today must adhere to strict policies for ensuring
Internet Security Cornerstones of Security Authenticity the sender (either client or server) of a message is who he, she or it claims to be Privacy the contents of a message are secret and only known to
OpenADR 2.0 Security Jim Zuber, CTO QualityLogic, Inc. Security Overview Client and server x.509v3 certificates TLS 1.2 with SHA256 ECC or RSA cipher suites TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256
FIPS 140-2 Security Policy LogRhythm 6.0.4 Log Manager LogRhythm 3195 Sterling Circle, Suite 100 Boulder CO, 80301 USA September 17, 2012 Document Version 1.0 Module Version 6.0.4 Page 1 of 23 Copyright
Secure Socket Layer Secure Socket Layer Introduction Overview of SSL What SSL is Useful For Introduction Secure Socket Layer (SSL) Industry-standard method for protecting web communications. - Data encryption
Chapter 17 Transport-Level Security Web Security Considerations The World Wide Web is fundamentally a client/server application running over the Internet and TCP/IP intranets The following characteristics
DRAFT ISDCF Doc5 - Guideline for KDMs and Certificates Behaviors Last revised 16 July 2012 1 KDM Formulations Actual DCI-compliant systems are now starting to appear in the field. Some KDM providers have
Contents Introduction--1 Content and Purpose of This Guide...........................1 User Management.........................................2 Types of user accounts2 Security--3 Security Features.........................................3
PKI Tutorial Jim Kleinsteiber February 6, 2002 Page 1 Outline Public Key Cryptography Refresher Course Public / Private Key Pair Public-Key Is it really yours? Digital Certificate Certificate Authority
Introduction to Cryptography Part 3: real world applications Jean-Sébastien Coron January 2007 Public-key encryption BOB ALICE Insecure M E C C D channel M Alice s public-key Alice s private-key Authentication
A Security Flaw in the X509 Standard Santosh Chokhani CygnaCom Solutions, Inc Abstract The CCITT X509 standard for public key certificates is used to for public key management, including distributing them
SecureDoc Disk Encryption Cryptographic Engine FIPS 140-2 Non-Proprietary Security Policy Abstract: This document specifies Security Policy enforced by SecureDoc Cryptographic Engine compliant with the
Security - 1 - OPC UA - Security Security Access control Wide adoption of OPC SCADA & DCS Embedded devices Performance Internet Scalability MES Firewalls ERP Communication between distributed systems OPC
Ciphire Mail Technical Introduction Abstract Ciphire Mail is cryptographic software providing email encryption and digital signatures. The Ciphire Mail client resides on the user's computer between the
SBClient SSL Ehab AbuShmais Agenda SSL Background U2 SSL Support SBClient SSL 2 What Is SSL SSL (Secure Sockets Layer) Provides a secured channel between two communication endpoints Addresses all three
Implementing SSL Security on a PowerExchange 9.1.0 Network 2012 Informatica Abstract This article describes how to implement SSL security on a PowerExchange network. To implement SSL security, configure
MPAA Site Security Program CONTENT SECURITY BEST PRACTICES SCREENER DIGITAL TRANSFER SERVICES Version 1.0 December 31, 2011 DOCUMENT HISTORY Version Date Description Author 1.0 December 31, 2011 Initial
TLS and SRTP for Skype Connect Technical Datasheet Copyright Skype Limited 2011 Introducing TLS and SRTP Protocols help protect enterprise communications Skype Connect now provides Transport Layer Security
ATSC Standard: ATSC Security and Service Protection Standard Doc. A/106 28 September 2015 Advanced Television Systems Committee 1776 K Street, N.W. Washington, D.C. 20006 202-872-9160 1 The Advanced Television
An Introduction to Cryptography as Applied to the Smart Grid Jacques Benoit, Cooper Power Systems Western Power Delivery Automation Conference Spokane, Washington March 2011 Agenda > Introduction > Symmetric
Understanding digital certificates Mick O Brien and George R S Weir Department of Computer and Information Sciences, University of Strathclyde Glasgow G1 1XH firstname.lastname@example.org, email@example.com
ISA Interoperability and Security Architecture A presentation by Julien Seligmann, COO, SmartJog SA HPA Technology Retreat 2006 International Developments in Digital Cinema ISA - Interoperability and Security
IoT Security Platform 2 Introduction Wars begin when the costs of attack are low, the benefits for a victor are high, and there is an inability to enforce law. The same is true in cyberwars. Today there
Apple Inc. Certificate Policy and Certification Practice Statement Version 2.0 Effective Date: April 10, 2015 Table of Contents 1. Introduction... 4 1.1. Trademarks... 4 1.2. Table of acronyms... 4 1.3.
Network Security Computer Networking Lecture 08 HKU SPACE Community College March 19, 2012 HKU SPACE CC CN Lecture 08 1/23 Outline Introduction Cryptography Algorithms Secret Key Algorithm Message Digest
Theater Key Retrieval (TKR) A System for Automated KDM Delivery 1 Introduction In Digital Cinema, the generation of KDMs is typically a highly automated process. However the delivery of those KDMs to the
Lecture topics Cryptography basics Using SSL to secure communication links in J2EE programs Programmatic use of cryptography in Java Cryptography basics Encryption Transformation of data into a form that
CRYPTOGRAPHY AS A SERVICE Peter Robinson RSA, The Security Division of EMC Session ID: ADS R01 Session Classification: Advanced Introduction Deploying cryptographic keys to end points such as smart phones,
Computer System Management: Hosting Servers, Miscellaneous Amarjeet Singh October 22, 2012 Partly adopted from Computer System Management Slides by Navpreet Singh Logistics Any doubts on project/hypo explanation
SSL BEST PRACTICES OVERVIEW THESE PROBLEMS ARE PERVASIVE 77.9% 5.2% 19.2% 42.3% 77.9% of sites are HTTP 5.2% have an incomplete chain 19.2% support weak/insecure cipher suites 42.3% support SSL 3.0 83.1%
DIGITAL RIGHTS MANAGEMENT SYSTEM FOR MULTIMEDIA FILES Saiprasad Dhumal * Prof. K.K. Joshi Prof Sowmiya Raksha VJTI, Mumbai. VJTI, Mumbai VJTI, Mumbai. Abstract piracy of digital content is a one of the
Dashlane Security Whitepaper November 2014 Protection of User Data in Dashlane Protection of User Data in Dashlane relies on 3 separate secrets: The User Master Password Never stored locally nor remotely.
Security in Wireless LANs and Mobile Networks Wireless Magnifies Exposure Vulnerability Information going across the wireless link is exposed to anyone within radio range RF may extend beyond a room or
Understanding and Integrating KODAK Picture Authentication Cameras Introduction Anyone familiar with imaging software such as ADOBE PHOTOSHOP can appreciate how easy it is manipulate digital still images.
Network Security Gaurav Naik Gus Anderson, Philadelphia, PA Lectures on Network Security Feb 12 (Today!): Public Key Crypto, Hash Functions, Digital Signatures, and the Public Key Infrastructure Feb 14:
2 MAC Message Authentication Codes : and Cryptography Sirindhorn International Institute of Technology Thammasat University Prepared by Steven Gordon on 28 October 2013 css322y13s2l08, Steve/Courses/2013/s2/css322/lectures/mac.tex,
ELE548 Research Essays CRYPTOGRAPHY IN NETWORK SECURITY AUTHOR: SHENGLI LI INSTRUCTOR: DR. JIEN-CHUNG LO Date: March 5, 1999 Computer network brings lots of great benefits and convenience to us. We can
Pulse Secure Network Connect Cryptographic Module Version 2.0 Non-Proprietary Security Policy Document Version 1.1 Pulse Secure, LLC. January 9, 2015 2015 by Pulse Secure, LLC. All rights reserved. May
PRIME IDENTITY MANAGEMENT CORE For secure enrollment applications processing and workflow management. PRIME Identity Management Core provides the foundation for any biometric identification platform. It
Network Security Abusayeed Saifullah CS 5600 Computer Networks These slides are adapted from Kurose and Ross 8-1 Public Key Cryptography symmetric key crypto v requires sender, receiver know shared secret
Efficiently handling SSL transactions is one cornerstone of your IT security infrastructure. Do you know how the protocol actually works? Wesley Chou Inside SSL: The Secure Sockets Layer Protocol Inside
How encryption works to provide confidentiality. How hashing works to provide integrity. How digital signatures work to provide authenticity and non-repudiation. How to obtain a digital certificate. Installing
Using etoken for SSL Web Authentication Lesson 12 April 2004 etoken Certification Course SSL V3.0 Overview Secure Sockets Layer protocol, version 3.0 Provides communication privacy over the internet. Prevents
2014 IBM Corporation This is the 27 th Q&A event prepared by the IBM License Metric Tool Central Team (ICT) Currently we focus on version 9.x of IBM License Metric Tool (ILMT) The content of today s session
Secure File Transfer Appliance Security Policy Document Version 1.9 Accellion, Inc. November 11, 2010 Copyright Accellion, Inc. 2010. May be reproduced only in its original entirety [without revision].
OOo Digital Signatures Malte Timmermann Technical Architect Sun Microsystems GmbH About the Speaker Technical Architect in OpenOffice.org/StarOffice development OOo/StarOffice developer since 1991/94 Main
CA DLP Release Notes for Advanced Encryption r12.0 This documentation and any related computer software help programs (hereinafter referred to as the "Documentation") are for your informational purposes
SSL/TLS: The Ugly Truth Examining the flaws in SSL/TLS protocols, and the use of certificate authorities. Adrian Hayter CNS Hut 3 Team firstname.lastname@example.org Contents Introduction to SSL/TLS Cryptography
; Digital Signatures and PKCS#11 Smart Cards Concepts, Issues and some Programming Details CALIFORNIA SOFTWARE LABS R E A L I Z E Y O U R I D E A S California Software Labs 6800 Koll Center Parkway, Suite
FIPS 140-2 Security Policy LogRhythm 6.0.4 or 6.3.4 Windows System Monitor Agent LogRhythm, Inc. 4780 Pearl East Circle Boulder, CO 80301 May 1, 2015 Document Version 2.0 Module Versions 6.0.4 or 6.3.4
Security Policy MOTOROLA MESSAGING SERVER SERVER AND MOTOROLA MYMAIL DESKTOP PLUS ENCRYPTION DLL CRYPTOGRAPHIC MODULE REV 1.3, 10/2002 CONTENTS Module Overview... 1 Scope of Document... 2 Terms and Definitions...
Efficient Framework for Deploying Information in Cloud Virtual Datacenters with Cryptography Algorithms Radhika G #1, K.V.V. Satyanarayana *2, Tejaswi A #3 1,2,3 Dept of CSE, K L University, Vaddeswaram-522502,
WHITE PAPER MANAGED FILE TRANSFER: 10 STEPS TO SOX COMPLIANCE 1. OVERVIEW Do you want to design a file transfer process that is secure? Or one that is compliant? Of course, the answer is both. But it s
HYBRID RSA-AES ENCRYPTION FOR WEB SERVICES AN IMPLEMENTATION OF HYBRID ENCRYPTION-DECRYPTION (RSA WITH AES AND SHA256) FOR USE IN DATA EXCHANGE BETWEEN CLIENT APPLICATIONS AND WEB SERVICES Kalyani Ganesh
Certificate Management PAN-OS Administrator s Guide Version 7.0 Contact Information Corporate Headquarters: Palo Alto Networks 4401 Great America Parkway Santa Clara, CA 95054 www.paloaltonetworks.com/company/contact-us
User Guide FIPS Mode For use with epolicy Orchestrator 4.6.x Software COPYRIGHT Copyright 2013 McAfee, Inc. Do not copy without permission. TRADEMARK ATTRIBUTIONS McAfee, the McAfee logo, McAfee Active
Lecture 31 Security April 13, 2005 Secure Sockets Layer (Netscape 1994) A Platform independent, application independent protocol to secure TCP based applications Currently the most popular internet crypto-protocol
Video Authentication for H.264/AVC using Digital Signature Standard and Secure Hash Algorithm Nandakishore Ramaswamy Qualcomm Inc 5775 Morehouse Dr, Sam Diego, CA 92122. USA email@example.com K.
Savitribai Phule Pune University Centre for Information and Network Security Course: Introduction to Cyber Security / Information Security Module : Pre-requisites in Information and Network Security Chapter
Lecture VII : Public Key Infrastructure (PKI) Internet Security: Principles & Practices John K. Zao, PhD (Harvard) SMIEEE Computer Science Department, National Chiao Tung University 2 Problems with Public
Northrop Grumman M5 Network Security SCS Linux Kernel Cryptographic Services FIPS Security Policy Version 2.42 www.northropgrumman.com/m5/ SCS Linux Kernel Cryptographic Services Security Policy Version
DEFENSE INFORMATION SYSTEMS AGENCY JOINT INTEROPERABILITY TEST COMMAND FORT HUACHUCA, ARIZONA DEPARTMENT OF DEFENSE PUBLIC KEY INFRASTRUCTURE EXTERNAL CERTIFICATION AUTHORITY MASTER TEST PLAN VERSION 1.0
Security Policy for Oracle Advanced Security Option Cryptographic Module Version 1.0 September 1999 Prepared by Oracle Corporation A. Scope of Document This document describes the security policy for the