WO2016042361A1 - Generic encryption system for nonsecure datapaths - Google Patents

Generic encryption system for nonsecure datapaths Download PDF

Info

Publication number
WO2016042361A1
WO2016042361A1 PCT/IB2014/064633 IB2014064633W WO2016042361A1 WO 2016042361 A1 WO2016042361 A1 WO 2016042361A1 IB 2014064633 W IB2014064633 W IB 2014064633W WO 2016042361 A1 WO2016042361 A1 WO 2016042361A1
Authority
WO
WIPO (PCT)
Prior art keywords
format
data
authentication
adaptation layer
data path
Prior art date
Application number
PCT/IB2014/064633
Other languages
French (fr)
Inventor
A.A. Jithra ADIKARI
Jean-Pierre Thibault
Original Assignee
Elliptic Technologies Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Elliptic Technologies Inc. filed Critical Elliptic Technologies Inc.
Priority to PCT/IB2014/064633 priority Critical patent/WO2016042361A1/en
Publication of WO2016042361A1 publication Critical patent/WO2016042361A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • GPHYSICS
    • G09EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09CCIPHERING OR DECIPHERING APPARATUS FOR CRYPTOGRAPHIC OR OTHER PURPOSES INVOLVING THE NEED FOR SECRECY
    • G09C1/00Apparatus or methods whereby a given sequence of signs, e.g. an intelligible text, is transformed into an unintelligible sequence of signs by transposing the signs or groups of signs or by replacing them by others according to a predetermined system
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0631Substitution permutation network [SPN], i.e. cipher composed of a number of stages or rounds each involving linear and nonlinear transformations, e.g. AES algorithms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]

Definitions

  • the present disclosure relates to encryption and content protection for nonsecure datapaths.
  • a secure generic encryption system for nonsecure datapaths comprises a format-specific adaptation layer/data path for receiving and processing data which is to be encrypted and/or decrypted; an authentication engine located within a security perimeter and coupled to an external communication interface for authentication and supplying the format-specific adaptation layer/data path, located outside the security perimeter, with an output signal indicating whether authentication is successful; and a secure generic encryption module located within the security perimeter and coupled (1) to the authentication engine for receiving from the authentication engine initialization vectors, encryption keys, and the output signal indicating whether authentication is successful, and (2) to the format-specific adaptation layer/data path for (a) receiving a read signal from the format-specific adaptation layer/data path, and (b) providing the format- specific adaptation layer/data path with a data-available signal to indicate whether data is available to be read.
  • the generic encryption module provides the format- specific adaptation layer/data path with encrypted data and the format-specific adaptation layer/data path may optionally provide the generic encryption module with custom encryption input data that is format-specific.
  • the authentication engine may provide the generic encryption module with a mode input.
  • FIG. 1 is a block diagram of a generic encryption system for HDCP content data.
  • HDCP 2.x There are seven distinct High-bandwidth Digital Content Protection HDCP 2.x specifications, each for a different audio/visual (A/V) transport mechanism: DisplayPort (DP), High-Definition Multimedia Interface (HDMI), Interface Independent Adaptation (IIA), Mobile High-definition Link (MHL), Digital interface for Video and Audio (DiiVA), Wireless Home Digital Interface (WHDI), Wireless High Defition (WirelessHD).
  • DP DisplayPort
  • HDMI High-Definition Multimedia Interface
  • IIA Interface Independent Adaptation
  • MHL Mobile High-definition Link
  • WiiVA Digital interface for Video and Audio
  • WPDI Wireless Home Digital Interface
  • WirelessHD Wireless High Defition
  • AES Advanced Encryption Standard
  • encryption module 101 can be paired with one or more external format-specific adaptation layer modules and the architecture can be used in the implementation of all HDCP 2.x variants to provide complete separation between the format- specific logic 102 and the elements of the protocol which must be kept confidential. Since the confidential elements of the protocol are kept away from the format-specific logic, the format-specific logic 102 does not need to reside in a trusted security perimeter 103; thus increasing design flexibility.
  • a key aspect to achieve the security perimeter is in the use of a signal 104 which indicates whether or not HDCP authentication has been achieved (authentication is handled by a separate authentication engine module 105).
  • encryption keys 111 and initialization material 112 are used to encrypt a counter sequence.
  • the external format-specific module uses this sequence to encrypt or decrypt the actual A/V stream. As soon as authentication is lost, the encryption module discards any previously encrypted counters.
  • One instance of the encryption module can be used to support more than one A/V format.
  • multiple encrypted data outputs may be provided to efficiently support simultaneous processing of multiple streams, which can be required for DisplayPort, WHDI, and DiiVA.
  • the security perimeter 103 is set such that untrusted format-specific modules may be plugged in without compromising security.
  • the encryption module 101 has a uni-directional interface with inputs coming from a separate module 105 which implements the HDCP authentication.
  • the authenticated signal 104 is a single-bit signal which indicates whether the system is currently in an authenticated state. If set to 1, then valid key(s) 111 and Initialization Vectors IV(s) 112 are expected on the encryption module 101 inputs. A 0 to 1 transition on the authenticated signal 104 resets the internal block counter which forms part of the AES counter (this is inputCtr in the HDCP specs). In some cases (i.e. DisplayPort) this is all the information that the encryption module needs to encrypt AES blocks. In other cases, additional information from the non-secure side is needed before encryption can begin, which is indicated by the "mode" input 113.
  • a one (1) to zero (0) transition on the authentication signal causes the encryption module to discard any encrypted blocks that have not yet been retrieved by the non-secure side. The module then waits for authentication to be re-established before generating AES-encrypted blocks again.
  • the encryption module 101 interfaces with the format-specific adaptation layer 102.
  • One or more data interfaces 120a... 120x provide encrypted data. In the case of AES, these are 128-bit encrypted AES words. However, different widths and other encryption algorithms are also possible.
  • the encryption module 101 signals whether data is available to be read with the "data available" signal 125; the adaptation layer fetches data by asserting the "read” signal 120.
  • the adaptation layer For most A/V formats, the adaptation layer generally supplies some information to the encryption module 101. This is pushed over the "optional custom encryption data" interface 126, which is a simple FIFO interface onto which the non-secure side pushes format-specific data.
  • DP does not need this interface, but the others (HDMI, IIA, MHL, DiiVA, WHDI and WirelessHD) generally do, each in slightly different ways.
  • the "mode” input determines the data that must be pushed onto this interface for example:
  • HDMI 38-bit frame number
  • DiiVA 32-bit stream counter, audio/video stream selector
  • WHDI 64-bit counter, coarse/fine stream selector
  • WirelessHD 8-bit stream index and 40-bit secure packet counter
  • one FIFO write triggers the encryption module to produce one data block, using the supplied data, as per the respective HDCP specifications.
  • DP is unique among the HDCP 2.x protected formats in using a single-bit "Type" variable in the encryption of the data.
  • the Type variable composes part of the IV used for the AES encryption. Since DP allows for multiple streams to be carried over a single physical interface, each with their own Type, two encrypted counter streams are required to encrypt/decrypt the DP data (one encrypted stream with Type set to zero (0), another one with Type set to one (1)).
  • Type is actually an 8-bit field; therefore other values of Type may be defined in the future, and the embodiment described can support it.
  • the different encryption streams can share a common key or have distinct keys.
  • the encryption module can be extended to multiple authentication sessions supporting several instances of A/V streams. [0024] This description is specific to the HDCP 2.x specs but it is also applicable to any other standards or protocols used for authentication, cryptographic algorithms and other AES modes other than AES-CTR.
  • Any algorithm, software, or method disclosed herein can be embodied in software stored on a non-transitory tangible medium such as, for example, a flash memory, a CD-ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), or other memory devices, but persons of ordinary skill in the art will readily appreciate that the entire algorithm and/or parts thereof could alternatively be executed by a device other than a controller and/or embodied in firmware or dedicated hardware in a well known manner (e.g., it may be implemented by an application specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable logic device (FPLD), discrete logic, etc.).
  • ASIC application specific integrated circuit
  • PLD programmable logic device
  • FPLD field programmable logic device
  • machine-readable instructions represented in any flowchart depicted herein can be implemented manually as opposed to automatically by a controller, processor, or similar computing device or machine.
  • specific algorithms are described with reference to flowcharts depicted herein, persons of ordinary skill in the art will readily appreciate that many other methods of implementing the example machine readable instructions may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined.

Abstract

A secure generic encryption system for nonsecure datapaths comprises a format- specific adaptation layer/data path for receiving and processing nonsecure content data; an authentication engine located within a security perimeter and coupled to an external communication interface for authentication and supplying the format-specific adaptation layer/data path, located outside the security perimeter, with an output signal indicating whether authentication is successful; and a generic encryption module located within the security perimeter and coupled (1) to the authentication engine for receiving from the authentication engine initialization vectors, encryption keys, and the output signal indicating whether authentication is successful, and (2) to the format-specific adaptation layer/data path for (a) receiving a read signal from the format-specific adaptation layer/data path, and (b) providing the format-specific adaptation layer/data path with a data-available signal to indicate whether data is available to be read.

Description

GENERIC ENCRYPTION SYSTEM FOR NONSECURE DATAPATHS
FIELD OF THE INVENTION
[0001] The present disclosure relates to encryption and content protection for nonsecure datapaths.
SUMMARY
[0002] In accordance with one embodiment, a secure generic encryption system for nonsecure datapaths comprises a format-specific adaptation layer/data path for receiving and processing data which is to be encrypted and/or decrypted; an authentication engine located within a security perimeter and coupled to an external communication interface for authentication and supplying the format-specific adaptation layer/data path, located outside the security perimeter, with an output signal indicating whether authentication is successful; and a secure generic encryption module located within the security perimeter and coupled (1) to the authentication engine for receiving from the authentication engine initialization vectors, encryption keys, and the output signal indicating whether authentication is successful, and (2) to the format-specific adaptation layer/data path for (a) receiving a read signal from the format-specific adaptation layer/data path, and (b) providing the format- specific adaptation layer/data path with a data-available signal to indicate whether data is available to be read.
[0003] In one implementation, the generic encryption module provides the format- specific adaptation layer/data path with encrypted data and the format-specific adaptation layer/data path may optionally provide the generic encryption module with custom encryption input data that is format-specific. The authentication engine may provide the generic encryption module with a mode input.
[0004] The foregoing and additional aspects and embodiments of the present disclosure will be apparent to those of ordinary skill in the art in view of the detailed description of various embodiments and/or aspects, which is made with reference to the drawings, a brief description of which is provided next. BRIEF DESCRIPTION OF THE DRAWINGS
[0005] FIG. 1 is a block diagram of a generic encryption system for HDCP content data.
[0006] While the present disclosure is susceptible to various modifications and alternative forms, specific embodiments or implementations have been shown by way of example in the drawings and will be described in detail herein. It should be understood, however, that the disclosure is not intended to be limited to the particular forms disclosed. Rather, the disclosure is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of an invention as defined by the appended claims.
DETAILED DESCRIPTION
[0007] There are seven distinct High-bandwidth Digital Content Protection HDCP 2.x specifications, each for a different audio/visual (A/V) transport mechanism: DisplayPort (DP), High-Definition Multimedia Interface (HDMI), Interface Independent Adaptation (IIA), Mobile High-definition Link (MHL), Digital interface for Video and Audio (DiiVA), Wireless Home Digital Interface (WHDI), Wireless High Defition (WirelessHD). They all use the Advanced Encryption Standard (AES) encryption algorithm in counter mode; however the counter is defined slightly differently in each specification.
[0008] The different definitions make it difficult to develop a common hardware module for more than one HDCP specifications, while also adhering to the confidentiality and integrity requirements of HDCP.
[0009] There is a need for an encryption module which can be used for all HDCP 2.x variants and which supports HDCP's confidentiality and integrity requirements.
[0010] Referring to FIG.1, encryption module 101 can be paired with one or more external format-specific adaptation layer modules and the architecture can be used in the implementation of all HDCP 2.x variants to provide complete separation between the format- specific logic 102 and the elements of the protocol which must be kept confidential. Since the confidential elements of the protocol are kept away from the format-specific logic, the format-specific logic 102 does not need to reside in a trusted security perimeter 103; thus increasing design flexibility.
[0011] A key aspect to achieve the security perimeter is in the use of a signal 104 which indicates whether or not HDCP authentication has been achieved (authentication is handled by a separate authentication engine module 105). When authenticated, encryption keys 111 and initialization material 112 are used to encrypt a counter sequence. The external format-specific module uses this sequence to encrypt or decrypt the actual A/V stream. As soon as authentication is lost, the encryption module discards any previously encrypted counters.
[0012] One instance of the encryption module can be used to support more than one A/V format.
[0013] Optionally, multiple encrypted data outputs may be provided to efficiently support simultaneous processing of multiple streams, which can be required for DisplayPort, WHDI, and DiiVA.
[0014] The security perimeter 103 is set such that untrusted format-specific modules may be plugged in without compromising security.
[0015] The encryption module 101 has a uni-directional interface with inputs coming from a separate module 105 which implements the HDCP authentication. The authenticated signal 104 is a single-bit signal which indicates whether the system is currently in an authenticated state. If set to 1, then valid key(s) 111 and Initialization Vectors IV(s) 112 are expected on the encryption module 101 inputs. A 0 to 1 transition on the authenticated signal 104 resets the internal block counter which forms part of the AES counter (this is inputCtr in the HDCP specs). In some cases (i.e. DisplayPort) this is all the information that the encryption module needs to encrypt AES blocks. In other cases, additional information from the non-secure side is needed before encryption can begin, which is indicated by the "mode" input 113.
[0016] A one (1) to zero (0) transition on the authentication signal causes the encryption module to discard any encrypted blocks that have not yet been retrieved by the non-secure side. The module then waits for authentication to be re-established before generating AES-encrypted blocks again.
[0017] The encryption module 101 interfaces with the format-specific adaptation layer 102. One or more data interfaces 120a... 120x provide encrypted data. In the case of AES, these are 128-bit encrypted AES words. However, different widths and other encryption algorithms are also possible. The encryption module 101 signals whether data is available to be read with the "data available" signal 125; the adaptation layer fetches data by asserting the "read" signal 120. [0018] For most A/V formats, the adaptation layer generally supplies some information to the encryption module 101. This is pushed over the "optional custom encryption data" interface 126, which is a simple FIFO interface onto which the non-secure side pushes format-specific data. Of the FIDCP 2.x formats, DP does not need this interface, but the others (HDMI, IIA, MHL, DiiVA, WHDI and WirelessHD) generally do, each in slightly different ways. The "mode" input determines the data that must be pushed onto this interface for example:
HDMI: 38-bit frame number
IIA: 32-bit stream counter
MHL: 32-bit stream counter
DiiVA: 32-bit stream counter, audio/video stream selector
WHDI: 64-bit counter, coarse/fine stream selector
WirelessHD: 8-bit stream index and 40-bit secure packet counter
[0019] For all modes, one FIFO write triggers the encryption module to produce one data block, using the supplied data, as per the respective HDCP specifications.
[0020] DP is unique among the HDCP 2.x protected formats in using a single-bit "Type" variable in the encryption of the data. The Type variable composes part of the IV used for the AES encryption. Since DP allows for multiple streams to be carried over a single physical interface, each with their own Type, two encrypted counter streams are required to encrypt/decrypt the DP data (one encrypted stream with Type set to zero (0), another one with Type set to one (1)).
[0021] Since both Type streams for DP use a common encryption key, it is possible to economize on HW resources by sharing the AES key expansion logic between the two encryption streams.
[0022] To generalize, for example, only two Type values are currently defined for DP, but Type is actually an 8-bit field; therefore other values of Type may be defined in the future, and the embodiment described can support it. The different encryption streams can share a common key or have distinct keys.
[0023] The encryption module can be extended to multiple authentication sessions supporting several instances of A/V streams. [0024] This description is specific to the HDCP 2.x specs but it is also applicable to any other standards or protocols used for authentication, cryptographic algorithms and other AES modes other than AES-CTR.
[0025] Although the algorithms described above including those with reference to the foregoing flow charts have been described separately, it should be understood that any two or more of the algorithms disclosed herein can be combined in any combination. Any of the methods, algorithms, implementations, or procedures described herein can include machine- readable instructions for execution by: (a) a processor, (b) a controller, and/or (c) any other suitable processing device. Any algorithm, software, or method disclosed herein can be embodied in software stored on a non-transitory tangible medium such as, for example, a flash memory, a CD-ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), or other memory devices, but persons of ordinary skill in the art will readily appreciate that the entire algorithm and/or parts thereof could alternatively be executed by a device other than a controller and/or embodied in firmware or dedicated hardware in a well known manner (e.g., it may be implemented by an application specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable logic device (FPLD), discrete logic, etc.). Also, some or all of the machine-readable instructions represented in any flowchart depicted herein can be implemented manually as opposed to automatically by a controller, processor, or similar computing device or machine. Further, although specific algorithms are described with reference to flowcharts depicted herein, persons of ordinary skill in the art will readily appreciate that many other methods of implementing the example machine readable instructions may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined.
[0026] It should be noted that the algorithms illustrated and discussed herein as having various modules which perform particular functions and interact with one another. It should be understood that these modules are merely segregated based on their function for the sake of description and represent computer hardware and/or executable software code which is stored on a computer-readable medium for execution on appropriate computing hardware. The various functions of the different modules and units can be combined or segregated as hardware and/or software stored on a non-transitory computer-readable medium as above as modules in any manner, and can be used separately or in combination. [0027] While particular implementations and applications of the present disclosure have been illustrated and described, it is to be understood that the present disclosure is not limited to the precise construction and compositions disclosed herein and that various modifications, changes, and variations can be apparent from the foregoing descriptions without departing from the spirit and scope of an invention as defined in the appended claims.

Claims

WHAT IS CLAIMED IS:
1. A generic encryption system for nonsecure datapaths, said system comprising a format-specific adaptation layer/data path for receiving and processing nonsecure content data,
an authentication engine located within a security perimeter and coupled to an external communication interface for authentication and supplying said format-specific adaptation layer/data path, located outside said security perimeter, with an output signal indicating whether authentication is successful, and
a generic encryption module located within said security perimeter and coupled (1) to said authentication engine for receiving from said authentication engine initialization vectors, encryption keys, and said output signal indicating whether authentication is successful, and (2) to said format-specific adaptation layer/data path for
receiving a read signal from said format-specific adaptation layer/data path, and
providing said format-specific adaptation layer/data path with a data-available signal to indicate whether data is available to be read.
2. The generic encryption system of claim 1 in which said generic encryption module provides said format-specific adaptation layer/data path with encrypted data.
3. The generic encryption system of claim 1 in which said format-specific adaptation layer/data path provides said generic encryption module with custom encryption data that is format-specific.
4. The generic encryption system of claim 1 in which said authentication engine provides said generic encryption module with a mode input.
5. The generic encryption system of claim 1 in which said format-specific adaptation layer/data path includes format-specific logic.
6. The generic encryption system of claim 1 in which said nonsecure datapath is a HDCP content data and said authentication is HDCP authentication.
7. A method of encrypting a nonsecure datapath, said method comprising receiving and processing nonsecure content data in a format-specific adaptation layer/data path for nonsecure content data,
supplying said format-specific adaptation layer/data path with
(i) an output signal, indicating whether authentication is successful, from an authentication engine located within a security perimeter and coupled to an external communication interface for authentication, and
(ii) a data-available signal, indicating whether data is available to be read, from a generic encryption module located within said security perimeter, and providing said generic encryption module with
(i) initialization vectors, encryption keys, and a signal indicating whether authentication is successful, from said authentication engine, and
(ii) a read signal from said format-specific adaptation layer/data path.
8. The method of claim 7 which includes providing said format-specific adaptation layer/data path with encrypted data from said generic encryption module.
9. The method of claim 7 which includes providing said generic encryption module with custom encryption data that is format-specific, from said format-specific adaptation layer/data path.
10. The method of claim 7 which includes providing said generic encryption module with a mode input, from said authentication engine.
11. The method of claim 7 in which said format-specific adaptation layer/data path includes format-specific logic.
12. The method of claim 7 wherein said nonsecure datapath is HDCP content data and said authentication is HDCP authentication.
PCT/IB2014/064633 2014-09-18 2014-09-18 Generic encryption system for nonsecure datapaths WO2016042361A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/IB2014/064633 WO2016042361A1 (en) 2014-09-18 2014-09-18 Generic encryption system for nonsecure datapaths

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/IB2014/064633 WO2016042361A1 (en) 2014-09-18 2014-09-18 Generic encryption system for nonsecure datapaths

Publications (1)

Publication Number Publication Date
WO2016042361A1 true WO2016042361A1 (en) 2016-03-24

Family

ID=55532611

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2014/064633 WO2016042361A1 (en) 2014-09-18 2014-09-18 Generic encryption system for nonsecure datapaths

Country Status (1)

Country Link
WO (1) WO2016042361A1 (en)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130145424A1 (en) * 2011-12-01 2013-06-06 Changliang Wang Secure provision of a digital content protection scheme

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130145424A1 (en) * 2011-12-01 2013-06-06 Changliang Wang Secure provision of a digital content protection scheme

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"ESM-20x: HDCP 2.2 for HDMI Embedded Security Module (Transmitter/Receiver/Repeater).", ELLIPTIC TECHNOLOGIES INC., 1 January 2013 (2013-01-01), Retrieved from the Internet <URL:http://www.elliptictech.com/imaees/stories/productbriefs/ESM-200-202HDCP2onHDMI.pdf> [retrieved on 20150429] *

Similar Documents

Publication Publication Date Title
US11169935B2 (en) Technologies for low-latency cryptography for processor-accelerator communication
JP6138333B2 (en) Master key encryption function for transmitter and receiver pairing as a countermeasure to thwart key recovery attacks
US20210203479A1 (en) Method and apparatus for decrypting and authenticating a data record
TWI736271B (en) Method, device and equipment for generating and using private key in asymmetric key
EP3014800B1 (en) Method and apparatus to encrypt plaintext data
US9509669B2 (en) Efficient routing of streams encrypted using point-to-point authentication protocol
US9143317B2 (en) Protecting against white box attacks using column rotation
US10027640B2 (en) Secure data re-encryption
JP2005110248A5 (en)
US9225708B2 (en) Method for authenticated encryption and decryption
AU2022100184A4 (en) System for and method of authenticating a component of an electronic device
US10277391B2 (en) Encryption device, encryption method, decryption device, and decryption method
US11368283B2 (en) Encryption and decryption engines with selective key expansion skipping
US20200045540A1 (en) Method and system for securing communication links using enhanced authentication
US10129019B2 (en) DP HDCP version converter
TWI672036B (en) Digital content protection over audio return data link device, method and storage medium
US9852312B2 (en) Generic encryption system for nonsecure datapaths
US9866538B2 (en) Data decryption circuit and associated method
EP4084484B1 (en) Method and device for encryption of video stream, communication equipment, and storage medium
WO2016042361A1 (en) Generic encryption system for nonsecure datapaths
JP5431191B2 (en) Authenticated stream cipher encryption apparatus, authenticated stream cipher decryption apparatus, encryption method, decryption method, and program
KR101668995B1 (en) Cryptographic device, system and method for security authentication using the same
KR102029550B1 (en) Design of hdcp for displayport
US10541979B2 (en) Multiport content encryption engine

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14902227

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 04.07.2017)

122 Ep: pct application non-entry in european phase

Ref document number: 14902227

Country of ref document: EP

Kind code of ref document: A1