SMPTE ST 430-5:2023-09
Revision of SMPTE ST 430-5:2011
SMPTE Standard
D-Cinema Operations — Security Log Event Class and Constraints
Approved - 2023-09-12
SMPTE (the Society of Motion Picture and Television Engineers) is an internationally-recognized standards developing organization. Headquartered and incorporated in the United States of America, SMPTE has members in over 80 countries on six continents. SMPTE’s Engineering Documents, including Standards, Recommended Practices, and Engineering Guidelines, are prepared by SMPTE’s Technology Committees. Participation in these Committees is open to all with a bona fide interest in their work. SMPTE cooperates closely with other standards-developing organizations, including ISO, IEC and ITU. SMPTE Engineering Documents are drafted in accordance with the rules given in its Standards Operations Manual.
At the time of publication no notice had been received by SMPTE claiming patent rights essential to the implementation of this Engineering Document. However, attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. SMPTE shall not be held responsible for identifying any or all such patent rights.
This document was prepared by Technology Committee 27C.
The following summarizes the changes from the previous edition of this document:
Copyright © 2024, Society of Motion Picture and Television Engineers. All rights reserved. No part of this material may be reproduced, by any means whatsoever, without the prior written permission of the Society of Motion Picture and Television Engineers.
This clause is entirely informative and does not form an integral part of this Engineering Document.
A general specification for D-Cinema Log Records and Log Reports is specified in SMPTE ST 430-4. This Security Class standard defines a class, and an associated namespace, for Log Records for security logging. Additionally, this standard constrains the use and application of that format to Security Log Records and Reports. More specifically, this document specifies the format of Log Records produced by security devices within D-Cinema systems. Typically these records are produced by the Security Manager component of the system, which produces records of security events for consumption by systems external to the security system. When the Security Manager produces these records, they are constructed to support authentication and non-repudiation by and for the device that produces them. Support is included for authenticating chains of records in a manner that reduces the overhead that would otherwise result if each record were to be authenticated individually.
The purpose of this document is to specify a Security Event Class and namespace for Security Log Records; and to constrain individual Log Records and sequences of such records (Log Reports) as they are used for security event logging purposes in D-Cinema applications. The items covered contain descriptions of events logged by the security system, which are intended to provide forensic information regarding security-critical events. This document does not specify the means of communication or the format of messaging between security devices in a system. Neither does this document define the format for storage of Log Events within the protected storage of a security device. The Security Log Records and Security Log Record Sequences (Log Reports) described herein are intended for reporting of Security Events previously recorded by the security system to consumers of that information which are external to the security system.
Normative text is text that describes elements of the design that are indispensable or contains the conformance language keywords: "shall", "should", or "may". Informative text is text that is potentially helpful to the user, but not indispensable, and can be removed, changed, or added editorially without affecting interoperability. Informative text does not contain any conformance keywords.
All text in this document is, by default, normative, except: the Introduction, any clause explicitly labeled as "Informative" or individual paragraphs that start with "Note:"
The keywords "shall" and "shall not" indicate requirements strictly to be followed in order to conform to the document and from which no deviation is permitted.
The keywords, "should" and "should not" indicate that, among several possibilities, one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited.
The keywords "may" and "need not" indicate courses of action permissible within the limits of the document.
The keyword "reserved" indicates a provision that is not defined at this time, shall not be used, and may be defined in the future. The keyword "forbidden" indicates "reserved" and in addition indicates that the provision will never be defined in the future.
A conformant implementation according to this document is one that includes all mandatory provisions ("shall") and, if implemented, all recommended provisions ("should") as described. A conformant implementation need not implement optional provisions ("may") and need not implement them as described.
Unless otherwise specified, the order of precedence of the types of normative information in this document shall be as follows: Normative prose shall be the authoritative definition; Tables shall be next; then formal languages; then figures; and then any other language forms.
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
For the purposes of this document, the following terms and definitions apply:
The fundamental purpose of security logging in D-Cinema systems is to assure that access to cleartext content, and the use of decryption keys to accomplish this, can be tracked in trusted reports from the security system. An important corollary of this requirement is to record that the security system itself is functioning properly. The Security Manager component of the security system is the trusted device, which collects information as the system operates, then processes that information to compose Security Log Records and potentially Log Reports. While communication of Log Event data between devices in a security system must be performed securely, such communications are outside of the scope of this document. This document does not specify any particular security system architecture, and so uses the term "Security Device" to refer to components of the security system generically.
The general requirements for Security Log Records external to the security system are that the records be verifiable as to the integrity of their content, verifiable as to the completeness of a report, and verifiable as to their source. An additional requirement is that sequences of log records must support filtering of potentially sensitive information, while maintaining sequential integrity, i.e., the filtering of an individual record must leave verifiable evidence of the record's existence and position in the sequence. Filtering is described in SMPTE ST 430-4.
When a system external to the security system, such as a general-purpose log management system, is instructed to retrieve records from the security system, this standard describes how those records should be generated and represented. The SMPTE ST 430-4 standard is constructed to support filtering of log records by omitting the body part of a record. The security system may support the generation of pre-filtered log record sequences (with selected record bodies omitted), or filtering may be performed after the log records are retrieved.
Clause 7 constrains the application of the log format defined in SMPTE ST 430-4. These constraints ensure that this format is applied to the expression of Log Records and Reports in a manner that provides for authentication of the log data.
It is important to note that SMPTE ST 430-4 does not actually specify the Event Types, Event SubTypes, Parameters, or scopes for the Event Classes that it denotes, but provides a framework for doing so. Clause 8 defines the security Event Class as called for in SMPTE ST 430-4, including all of the detail necessary to create fully defined Log Records for security.
Any event that has security implications or forensic value. Such an event results in the recording of log data.
Security event information that is recorded and stored within a security device, where such an event took place or was observed.
A Log Record, containing Security Log Data, describing a Security Log Event.
A sequence of Log Records as specified in SMPTE ST 430-4 and subject to the constraints specified in this document.
A generic term, which refers to a physical or logical device which contains or uses a D-Cinema security certificate, and which performs a D-Cinema security function.
A logical entity that implements one or more D-Cinema security-related processes, e.g., a Media Decryptor (MD) or a Forensic Marker.
A tamper-resistant, -evident and -responsive perimeter associated with a Digital Certificate around security-critical information. The specific characteristics of the perimeter are outside the scope of this specification.
The combination of Image Decryptor, Audio Decryptor, Forensic Marker(s), Security Manager and (optionally) Link Encryptor Security Entities contained within a single Secure Processing Block.
A Secure Processing Block other than the Image Media Block.
A Security Entity that is implemented within a Media Block, responsible for parsing Key Delivery Messages and generating Log Records.
NOTE — There can be more than one Media Block, and therefore more than one Security Manager associated with an auditorium within an exhibition site.
A logical entity associated with a Digital Certificate responsible for content management and validation within an auditorium.
SPB Marriage and Divorce consist in the creation and termination, respectively, of a persistent, monitored connection (electrical and physical) between two Secure Processing Blocks.
Forensic Marking (FM) is the embedding of tracking information into sound and/or image essence by the Image Media Block during playback.
SPB Shutdown and Initialization mean that execution of the firmware on the SPB has been terminated or started, respectively.
An integer that increments by one for each successive Encrypted Triplet contained in a given essence track (see SMPTE ST 429-6).
The Main Asset in a CPL shall be the Main Picture asset if present. If the Main Picture asset is not present, the Main Asset shall be the picture related asset that references the picture elements to be projected on the main screen. If no main screen picture related asset is present in the CPL, the Main Asset shall be the first asset — according to the Reel assets sequence order defined in SMPTE ST 429-7 — that is used in the CPL Reels.
A Composition Playlist is valid if all of the following conditions are satisfied:
The Frame Playback Process consists of:
A complete composition playlist (CPL) playback is the playback of a composition Playlist from the first edit unit of the first Reel to the last edit unit of the last Reel without exception, operator intervention or other interruptions.
This document defines and constrains the Security Log Event Class. Log Records of this class shall conform to the specifications and constraints in this document. This document also defines Event Types and Event SubTypes for the Security Event Class. Log Records in this class shall be identified by the URI of the Security Class Namespace Name defined in 6.4 appearing in the EventClass element of the Log Record Header as defined in SMPTE ST 430-4.
NOTE — The Security Event Class only includes events which are specifically and clearly security related. Other events that occur in the system could be construed as security related or not, depending upon individual interpretation, and upon whether or not they can reasonably occur in normal operation or equipment service. For example, logging a short loss of power, or the theft of an entire system, is outside of the scope of this standard.
This document declares fragment identifiers in an XML namespace, whose Namespace Name (URI) shall be:
http://www.smpte-ra.org/430-5/2008/SecurityLog/
There are no types defined in this namespace.
Table 1 defines the namespace prefixes used in the XSDL and XML examples in this document. Please refer to Clause 3 and to SMPTE ST 433 for specific references to the namespaces referred to in this table. Note that the prefixes themselves are not normative, and that instance documents may assign alternative prefixes in practice.
| Prefix | Namespace Reference |
|---|---|
| xs | XML Schema Part 1: Structures |
| ds | XML Signature Syntax and Processing |
| xsi | XML Schema Part 1: Structures |
| dcml | SMPTE ST 433 |
| lr | SMPTE ST 430-4 |
This specification is based on the use of one of the two architectures depicted in Figure 1.
When a security system is requested to produce log records, that system should produce the records in a format based on SMPTE ST 430-4 as constrained by this document. Security Log Reports may contain any number of records. Security Devices may also provide status information through other means, such as real-time messaging, but such messages are not intended to be used as records of security events for forensic purposes, and are outside of the scope of this document.
When Log Records are created in a security context, the following constraints and requirements shall be applied to the structure and content of each Log Record and Log Report containing those records. These constraints shall be applied in addition to the constraints specified in SMPTE ST 430-4.
The following constraints shall apply to the use of elements in the Log Record Header of a Security Log Record.
All time stamps shall be derived from a secure time source located in the Security Device which recorded the event. The source or reference for that time source is outside of the scope of this document. The TimeStamp element of the Log Record Header shall be set to a value corresponding to the time that the Security Log Event was detected.
All Log Record Headers in a Security Log Report shall contain the EventSequence element. Within each signed sequence in a Security Log Report, the value of the EventSequence element in each Log Record shall increase strictly, i.e., shall never remain the same or decrease, throughout the sequence.
If a single Security Log Record is signed individually (not as part of a sequence), the EventSequence element of the Log Record Header shall not be present.
The DeviceSourceID list element in each Log Record Header shall contain the Certificate Thumbprint of the security device that reported or recorded the Security Log Event, i.e., the device that the Event applies to.
A Log Report may contain events which are not classified as Security Events. If such events are included, they shall be treated as part of the Log Record Sequence. When a logged event is a Security Event, the content of the EventClass element of the Log Record Header shall be the Security Class Namespace Name URI defined in 6.4 of this document. Events which shall be treated as Security Events are listed elsewhere in this document.
The previousHeaderHash element shall be required in all Log Record Headers, except on the first record in a sequence. If the previousHeaderHash field is included in the first record in a sequence, its value shall be zero expressed as a valid message digest value, i.e., the message digest of the value zero. The previousHeaderHash element shall be calculated according to the algorithm specified in SMPTE ST 430-4.
The recordBodyHash element shall be required in all Log Record Headers for all Security Events, whether the Log Record is part of a sequence or not. The recordBodyHash element shall be calculated according to the algorithm specified in SMPTE ST 430-4.
If the EventClass element in the Log Record Header is set to the Security Class Namespace URI as defined in 6.4, then the Event Type element shall be one of the Event Types defined in this document. If that Event Type requires parameters, the Parameters element of the associated Log Record Body shall be present and those parameters shall be supplied in the Parameters element of the Log Record Body.
The following constraints shall apply to the body of a Security Log Record defined in this class document.
If the Event Type of the associated Log Record Header requires an Event SubType, the EventSubType element shall be present in the log record body and shall contain one of the Event SubTypes defined in this document. If that Security Event Type or Event SubType requires parameters, the Parameters element of the Log Record Body shall be present, and those parameters shall be supplied in the Parameters list of the Log Record Body.
NOTE — Types, SubTypes, Parameters, and Type Scopes for Security Log Messages are specified in the Security Event Definitions clause of this document.
This item intentionally left blank.
If a Security Log Event relates to the processing of a Composition or a Track File, the Log Record Body shall include a ReferencedIDs list that shall contain a name/value pair whose IDName element shall contain either the token CompositionID or the token TrackfileID, and whose IDValue element shall contain the Composition Playlist Identifier or Track File Identifier, respectively. In the case of a Composition Playlist identifier, this value shall be the UUID taken from the Id element of the Composition Playlist Structure SMPTE ST 429-7. In the case of a Track File Identifier, this value shall be a UUID which shall be taken from the Package UID of the (sole) Top-level File Package of the identified Track File SMPTE ST 429-3, or the contents of the Id element of the Subtitle Reel element of a subtitle track file, or from such other unique identifiers as SMPTE may designate in Track Files defined in future standards.
A device that is not processing one of these entities directly, such as a Link Decryptor, may not know the identity of the content that it is processing. In that case, the composition or trackfile associated with that content may be inferred from the Log Record sequence, but the associated fields in the Log Record Body may be omitted by the reporting device.
If one of the Exceptions identified in the Event Sub Type Record descriptions in this document is detected, the Security Device shall include an Exception record as specified in the Event Sub Type definitions in 8.4.
Authenticated Log Records shall be required for all Security class Log Records in Log Reports. Thus Log Record Signatures shall be included as specified in SMPTE ST 430-4 and related clauses of this document, either on individual Log Records or on sequences of Log Records in Log Reports. Log Record Signatures placed at the end of a sequence or in a single record shall include the RecordAuthData element and its sub-elements, and shall include the Signature element. The Digest Method for the RecordAuthData element shall be SHA-1. The Signature Method for the SignedInfo element of the Signature shall be RSA-SHA-256.
In the Log Record Signature, the KeyInfo element shall be present and shall contain the entire certificate chain for the signer. The Object element shall not be present and the URI attribute of the Reference element shall be set to a unique string for each signed log record in a report, as the signature is detached. The Reference element shall contain a single DigestMethod element, with its Algorithm attribute set to the URI value http://www.w3.org/2000/09/xmldsig#sha1.
The CanonicalizationMethod shall be set to the URI value http://www.w3.org/TR/2001/REC-xml-c14n-20010315.
The SignatureMethod shall be set to the URI value http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 as defined at IETF RFC 9231.
The entire certificate chain shall be carried in the KeyInfo element as a sequence of X509Data elements. Each of the X509Data elements shall correspond to one certificate in the chain, and contain one X509IssuerSerial element and one X509Certificate element. The Distinguished Name value in all X509IssuerName elements shall conform with the Distinguished Name Encoding Rules specified in XML Signature Syntax and Processing.
Security Log Records and Reports shall be authenticated using the mechanisms described in SMPTE ST 430-4. Individual Log Records may be authenticated by signing each record individually. Security Log Reports shall consist of one or more sequences of Log Records in authenticated chains. Each sequence shall be signed by a Log Record Signature at the end of each sequence. Each Signature shall be signed with the Digital Cinema Certificate of the Security Device that generates the Log Record or sequence of Log Records.
SMPTE ST 430-4 defines a general format for Log Records. While that specification defines Event Classes, it leaves the specific definition of the content of the Event Classes to application specifications such as this one. In this clause, the Event Types, Event SubTypes, their scope identifiers, and Event Parameters for the Security Class are defined.
Each Security Log Record shall contain at least the following elements:
Within the security event class, the following types, SubTypes, scopes, and parameters shall represent a hierarchy of security event identifiers, which shall be used in the EventType, EventSubType, and Parameters elements of Security Log Record Body elements.
NOTE — See the definitions of the Named Parameter Type and the Parameter List Type in SMPTE ST 433 for a more complete explanation of XML Parameter Lists, and additional examples.
When parameters are specified in the Event SubType clauses below, a Security Log Record may include a RecordTextExtension element to additionally frame the parameters in a textual description of the Log Event. A logging device may also include additional parameters beyond the ones specified in the tables.
Within the ReferencedIDs element of the Log Record Body, The IDName element of each ReferencedID is a scopedTokenType. These tokens are defined in this clause. These tokens shall comprise a scope, which shall be represented by the following scope identifier in URI form:
http://www.smpte-ra.org/430-5/2008/SecurityLog/#EventTypes
Instance documents shall either use this scope for ReferenceID IDNames, or may create an extended scope which contains the same members as this scope, with the same meanings, as the basis for the extended scope. If no scope identifier is present in the IDName elements of the ReferenceID elements of the ReferenceIDs element of the Log Record Body, then this scope shall be taken as the default scope.
The Tokens that comprise this scope and the definitions of the UUIDs contained in the IDValue part of the corresponding name/value pair shall be as defined in the following table.
| Token | Description |
|---|---|
| KeyDeliveryMessageID | If present, the KeyDeliveryMessageID value shall be the UUID that identifies the Key Delivery Message currently being processed by the reporting device, if the event is related to key usage or key validation. This UUID shall be taken from the MessageId element of the Authenticated Public section of the KDM. |
| CompositionID | If present, the CompositionID value shall contain the UUID of the current composition at the time of the event, if any. This UUID shall be taken from the Id element of the Composition Playlist structure. |
| TrackFileID | If present, the TrackFileID value shall be the UUID of the current Track File which is the subject of the Log Event. As appropriate, this UUID shall either be the Package UID value of the (sole) Top-level File Package of the identified Track File, per SMPTE ST 429-3, or the contents of the Id element of the SubtitleReel element of a subtitle track file per SMPTE ST 429-5, or the designated unique identifier of other track file types that SMPTE may define. |
The content of the EventType element in the Log Record Header shall be a token from the following table. The set of tokens listed in this table shall be represented by the following scope identifier in URI form:
http://www.smpte-ra.org/430-5/2008/SecurityLog/#EventTypes
When a Security Log Record is created, the EventType element of the Log Record Header should include this scope attribute. If no scope attribute is included, but the EventClass element of the Log Record Header contains the value of the URI specified in 6.4, then this scope shall be taken to be the default scope. If a different scope attribute is included in the EventType element, that scope shall define the meaning of the EventType value. Any such alternate scope, where defined, shall also define Event SubTypes and Parameters for the tokens defined in that scope.
| Token | Description |
|---|---|
| Playout | Playout security Event type. Events related to content playout. |
| Validation | Security System Validation |
| Key | Key Related Event |
| ASM | Auditorium Security Message Event |
| Operations | An Event related to the operation of an SPB or an SPB’s contents. |
Each of the following SubType tables defines the SubTypes and parameters for one of the Event Types defined in the previous clause.
If the content of the EventType element is the Playout token, the content of the EventSubType element shall be a token from the following table. The set of tokens listed in this table shall be represented by the following scope identifier in URI form:
http://www.smpte-ra.org/430-5/2008/SecurityLog/#EventSubTypes-playout
| Token | Description |
|---|---|
| FrameSequencePlayed | Playout of a specified sequence of frames from a track file has been executed as defined in 6.2.2, or has failed to play because one or more exceptions have been detected per 7.2.3.5. |
| CPLStart | The first edit unit of the Main Asset of the first reel of a target CPL has been played by a device. |
| CPLEnd | The last edit unit of the Main Asset of the last Reel of a target CPL has been played by a device. |
| PlayoutComplete | The target CPL has been played without interruption of exception by a device as per 6.2.3. |
Each FrameSequencePlayed Record shall at a minimum contain the following elements with values as specified below. Note that this record will never be created for track files which are not encrypted per SMPTE ST 429-6.
If an attempt to play a sequence of frames fails, this Record shall be generated with an appropriate exception or exceptions.
In addition to the minimum elements, the following exceptions are defined in the case of an exception or playout interruption or failure. One or more exceptions may be listed in the Exceptions element of the Log Record. The following exceptions apply to FrameSequencePlayed records:
CheckValueError, FrameMICError, FrameSequenceError, TrackFileIDError, ContentAuthenticatorError, TDLError, KeyTypeError, ValidityWindowError, PlayoutInterrupt, IntegrityPackError, CPLProcessedCollectError. See 8.5 for definitions of these exceptions.
This record indicates that the first edit unit of the Main Asset of the first Reel of a Composition has been processed by a device. Each CPLStart record shall at a minimum contain the following elements with values as specified below.
No specific Exceptions are defined for this Record.
This record indicates that the last edit unit of the Main Asset of the last Reel of a Composition has been processed by a device. Each CPLEnd record shall at a minimum contain the following elements with values as specified below.
No specific Exceptions are defined for this record.
NOTE — The events that generate the CPLStart and CPLEnd records can be detected by noting a change in the contentId elements of successive FrameSequencePlayed events, except in the case where the same CPL is played twice in sequence.
This record indicates that a CPL has been processed without interruption or exception by a device as per 6.2.3 of this standard. Each PlayoutComplete Record shall at a minimum contain the following elements with values as specified below.
No specific Exceptions are defined for this Record.
If the content of the EventType element is the Validation token, the content of the EventSubType element shall be a token from the following table. The set of tokens listed in this table shall be represented by the following scope identifier in URI form:
http://www.smpte-ra.org/430-5/2008/SecurityLog/#EventSubTypes-validation
| Token | Description |
|---|---|
| CPLCheck | A CPL has been validated according to 6.2.1. |
Each CPLCheck Record shall at a minimum contain the following elements with values as specified below.
In addition to the minimum elements, the following exceptions are defined in the case of a validation failure. One or more exceptions may be listed in the Exceptions element of the Log Record. The following exceptions apply to CPLCheck records:
CPLFormatError, CertFormatError, AssetHashError, AssetMissingError, SignatureError. Refer to 8.5 for descriptions of these exceptions.
If the content of the EventType element is the Key token, the content of the EventSubType element shall be a token from the following table. The set of tokens listed in this table shall be represented by the following scope identifier in URI form:
http://www.smpte-ra.org/430-5/2008/SecurityLog/#EventSubTypes-key
| Token | Description |
|---|---|
| KDMKeysReceived | Indicates that a device has retrieved a list of plaintext keys from a given KDM. |
| KDMDeleted | Indicates that a device has permanently purged a KDM and its associated Keys. |
Each KDMKeysReceived Record shall at a minimum contain the following elements with values as specified below.
In addition to the minimum elements, the following exceptions are defined in the case of a processing failure. One or more exceptions may be listed in the Exceptions element of the Log Record. The following exceptions apply to KDMKeysReceived records:
KDMFormatError, CertFormatError, SignatureError. Refer to 8.5 for descriptions of these exceptions.
Each KDMDeleted Record shall at minimum contain the following elements with values as specified below.
No specific exceptions are defined for this record.
If the content of the EventType element is the ASM token, the content of the EventSubType element shall be a token from the following table. The set of tokens listed in this table shall be represented by the following scope identifier in URI form:
http://www.smpte-ra.org/430-5/2008/SecurityLog/#EventSubTypes-ASM
| Token | Description |
|---|---|
| LinkOpened | A link has been opened between two devices using the SMPTE ST 430-6 protocol. |
| LinkClosed | A TLS link specified by SMPTE ST 430-6 between two devices has been closed. |
| LinkException | An exception occurred on an open TLS link specified by SMPTE ST 430-6. |
| LogTransfer | A device has transferred a log record or records to another device on a TLS link specified by SMPTE ST 430-6. |
| KeyTransfer | A device has transmitted a key to another device on a TLS link specified by SMPTE ST 430-6. |
Each LinkOpened record shall at a minimum contain the following elements with values as specified below.
In addition to the minimum elements, the following exceptions are defined in the case of a link opening failure. One or more exceptions may be listed in the Exceptions element of the Log Record. The following exceptions apply to LinkOpened records:
CertFormatError, TLSError. Refer to 8.5 for the descriptions of these exceptions.
NOTE — The DeviceSourceID element in a LinkOpened Record may identify either the initiator or responder in an ASM connection.
Each LinkClosed record shall at a minimum contain the following elements with values as specified below.
In addition to the minimum elements, the following exception is defined in the case of a link close failure. One or more exceptions may be listed in the Exceptions element of the Log Record. The following exception applies to LinkClosed records:
TLSError. Refer to 8.5 for the description of this exception.
NOTE — The DeviceSourceID element in a LinkClosed Record may identify either the initiator or responder in an ASM connection.
Each LinkException record shall at a minimum contain the following elements with values as specified below. In addition to these elements, one or more exceptions may be included, or the UnknownError exception may be included if none of the defined exceptions are appropriate.
In addition to the minimum elements, the following exceptions are defined in the case of a link exception. One or more exceptions may be listed in the Exceptions element of the Log Record. The following exceptions apply to LinkException records:
QuerySPBError, QuerySPBAlert, ASMMessageError. Refer to 8.5 for the description of these exceptions.
Each LogTransfer record shall at a minimum contain the following elements with values as specified below. In addition to these elements, one or more exceptions may be included, or the UnknownError exception may be included if none of the defined exceptions are appropriate.
In addition to the minimum elements, the following exceptions are defined in the case of a LogTransfer error. One or more exceptions may be listed in the Parameters of the Log Message. The following exceptions apply to LogTransfer records:
ASMLogRequestFailed. Refer to 8.5 for the description of this exception.
NOTE — The DeviceSourceID element in a LogTransfer Record may identify either the initiator or responder in an ASM connection.
Each KeyTransfer record shall at a minimum contain the following elements with values as specified below. In addition to these elements, one or more exceptions may be included, or the UnknownError exception may be included if none of the defined exceptions are appropriate.
No specific exceptions are defined for this record.
NOTE — The DeviceSourceID in a KeyTransfer Record may identify either the initiator or responder in an ASM connection.
If the content of the EventType element is the Operations token, the content of the EventSubType element shall be a token from the following table. The set of tokens listed in this table shall be represented by the following scope identifier in URI form:
http://www.smpte-ra.org/430-5/2008/SecurityLog/#EventSubTypes-operations
| Token | Description |
|---|---|
| SPBOpen | An SPB perimeter has been opened |
| SPBClose | An SPB perimeter has been closed |
| SPBMarriage | Two SPBs have been Married per the definition in 6.1 of this standard. |
| SPBDivorce | Two SPBs have been Divorced per the definition in 6.1 of this standard. |
| SPBShutdown | The operating software of an SPB has shut down per the definition in 6.1 |
| SPBStartup | The operating software of an SPB has been started per the definition in 6.1 |
| SPBClockAdjust | The time of a secure clock within an SPB was adjusted. |
| SPBSoftware | The operating software of an SPB was modified. |
| SPBSecurityAlert | An SPB is reporting a Security Log Event not listed in this document. |
Each SPBOpen record shall at a minimum contain the following elements with values as specified below. In addition to these elements, one or more exceptions may be included, or the UnknownError exception may be included if none of the defined exceptions are appropriate.
No specific exceptions are defined for this record.
Each SPBClose record shall at a minimum contain the following elements with values as specified below. In addition to these elements, one or more exceptions may be included, or the UnknownError exception may be included if none of the defined exceptions are appropriate.
No specific exceptions are defined for this record.
Each SPBMarriage record shall at a minimum contain the following elements with values as specified below. In addition to these elements, one or more exceptions may be included, or the UnknownError exception may be included if none of the defined exceptions are appropriate.
No specific exceptions are defined for this record.
NOTE — This record may be logged by both of the partner SPBs.
Each SPBDivorce record shall at a minimum contain the following elements with values as specified below. In addition to these elements, one or more exceptions may be included, or the UnknownError exception may be included if none of the defined exceptions are appropriate.
No specific exceptions are defined for this record.
NOTE — This record may be logged by both of the partner SPBs.
Each SPBShutdown record shall at a minimum contain the following elements with values as specified below. In addition to these elements, one or more exceptions may be included, or the UnknownError exception may be included if none of the defined exceptions are appropriate.
No specific exceptions are defined for this record.
Each SPBStartup record shall at a minimum contain the following elements with values as specified below. In addition to these elements, one or more exceptions may be included, or the UnknownError exception may be included if none of the defined exceptions are appropriate.
No specific exceptions are defined for this record.
Each SPBClockAdjust record shall at a minimum contain the following elements with values as specified below. In addition to these elements, one or more exceptions may be included, or the UnknownError exception may be included if none of the defined exceptions are appropriate.
In addition to the minimum elements, the following exceptions are defined in the case of a clock adjustment error. One or more exceptions may be listed in the Exceptions element of the Log Message. The following exceptions apply to SPBClockAdjust records:
AdjustmentRangeError. Refer to 8.5 for the description of this exception.
Each SPBSoftware record shall at a minimum contain the following elements with values as specified below. In addition to these elements, one or more exceptions may be included, or the UnknownError exception may be included if none of the defined exceptions are appropriate.
In addition to the minimum elements, the following exceptions are defined in the case of an error. One or more exceptions may be listed in the Exceptions element of the Log Record. The following exceptions are defined for SPBSoftware records:
SoftwareFailure. Refer to 8.5 for the description of this exception.
Each SPBSecurityAlert record shall at a minimum contain the following elements with values as specified below. In addition to these elements, one or more additional parameters and one or more exceptions may be included, or the UnknownError exception may be included.
No specific exceptions are defined for this record.
NOTE — This record is intended to be used as a generic exception for the purpose of logging events associated with SPB functional aberrations or intermittent failures. Details of such events are expected to be added by implementers as additional parameters or exceptions to this Record. It would be helpful if implementers included a RecordTextExtension element to describe the nature of the event.
Table 9 defines standard tokens, which identify exceptions in Security Log Records, and describes the meaning of each exception when it is used. These standard tokens shall be used in the Name element of a name/value pair, and additional information about the exception may be provided in the Value element. If no additional information is available, the Value element of the name/value pair shall still be present. These name/value pairs shall be included in the Exceptions element of the Log Record Body as specified in SMPTE ST 430-4.
| Token | Description |
|---|---|
| CPLFormatError | Indicates that the CPL did not meet the normative language of SMPTE ST 429-7. |
| CertFormatError | Indicates that the Signer Certificate of the referenced object did not meet the normative language of SMPTE ST 430-2. |
| AssetHashError | Indicates that the computed hash of one of the assets referenced by the CPL did not match the value recorded in the optional Hash element of the Asset element of the CPL. |
| AssetMissingError | Indicates that one or more of the assets referenced in a CPL was not available. |
| SignatureError | Indicates that the digital signature of the referenced object did not validate. |
| KDMFormatError | Indicates that a KDM did not meet the normative Language of SMPTE ST 430-1. |
| CheckValueError | At least one Check Value within a range of frames processed did not match the Check Value specified in SMPTE ST 429-6. |
| FrameMICError | Indicates that a MIC check failed on one or more frames of a track file. |
| FrameSequenceError | Indicates that a frame sequence check failed on two or more frames of a track file. |
| TrackFileIDError | Indicates that a TrackFileID check against the associated CPL failed. |
| ContentAuthenticatorError | Indicates that the Signer of a CPL does not match the Content Authenticator of a KDM that enables that CPL. See SMPTE ST 430-1. |
| TDLError | At least one downstream device from a media block did not appear on the TDL of the KDM that was to be used to decrypt content. |
| KeyTypeError | A KDM supplied a key of the wrong KeyType for a track file, e.g., an image track file KeyID pointed to an audio KeyType in the KDM. See SMPTE ST 430-1. |
| ValidityWindowError | Indicates that decryption failed due to an attempt to use a KDM outside of its validity window. |
| PlayoutInterrupt | Indicates that a playout was paused or restarted. |
| IntegrityPackError | Indicates that a playout was disallowed or terminated due to missing content integrity pack metadata. |
| CPLProcessedCollectError | Indicates that a playout was disallowed or terminated due to failure to meet playout log collection requirements. |
| TLSError | Indicates that a connection specified in SMPTE ST 430-6 detected an error in an underlying TLS session. |
| UnknownError | Indicates that an unspecified error occurred. |
| QuerySPBError | (Initiator Only) A responder failed to respond to a QuerySPB message per the requirements of SMPTE ST 430-6. |
| QuerySPBAlert | (Initiator Only) A responder returned a Security Alert response to a QuerySPB command from an initiator per SMPTE ST 430-6. |
| ASMMessageError | Either an initiator or a responder received a request or response that did not meet the normative requirements of SMPTE ST 430-6. |
| ASMLogRequestFailed | A log transfer request did not result in a complete response per SMPTE ST 430-6. |
| SoftwareFailure | Replacement or modification of software on an SPB failed. |
| AdjustmentRangeError | An attempt to make an adjustment outside of an allowable range failed. |
An example Log Report instance is provided as Element a.
A Security Device that produces Security Log Records for Security Log Events that are reported by another Security Device via an authenticated secure channel performs this function as a proxy for the logging function. By acting as a proxy, it implicitly asserts that it has authenticated the other Security Device, and has established a secure channel to receive the Security Log Data that constitutes the proxy Logged Security Log Events. Constraints on this proxy function or the security properties of the authenticated secure channel are outside of the scope of this document.
In order to support confidentiality requirements of Log Event reporting, while at the same time assuring that Log Report tampering is detected, this specification supports Log Report Filtering. Log Reports may be filtered to remove the Log Record Body section of any selected records, while preserving the associated Log Record Header for all Log Records in the report. Recipients may examine a filtered Log Report that records content key usage over a period of time, for example, and verify that no records have been deleted from the report, although not all record bodies may be present.
Verification of Log Report Header chaining and Log Body Data validation are described in SMPTE ST 430-4.
This annex lists non-prose elements of this document.