CN106464491B - Hardware receiver device - Google Patents
Hardware receiver device Download PDFInfo
- Publication number
- CN106464491B CN106464491B CN201480079283.1A CN201480079283A CN106464491B CN 106464491 B CN106464491 B CN 106464491B CN 201480079283 A CN201480079283 A CN 201480079283A CN 106464491 B CN106464491 B CN 106464491B
- Authority
- CN
- China
- Prior art keywords
- frame
- content
- mode
- encryption
- authorization
- Prior art date
- Legal status (The legal status 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 status listed.)
- Active
Links
- 238000013475 authorization Methods 0.000 claims abstract description 42
- 230000004224 protection Effects 0.000 claims description 6
- 238000000034 method Methods 0.000 description 6
- 230000005540 biological transmission Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 238000004891 communication Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/12—Transmitting and receiving encryption devices synchronised or initially set up in a particular manner
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic 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
- H04L9/3263—Cryptographic 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 involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
- H04N21/4363—Adapting the video stream to a specific local network, e.g. a Bluetooth® network
- H04N21/43632—Adapting the video stream to a specific local network, e.g. a Bluetooth® network involving a wired protocol, e.g. IEEE 1394
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
- H04N21/44008—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving operations for analysing video streams, e.g. detecting features or characteristics in the video stream
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
- H04N21/4405—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video stream decryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
- H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
- H04N21/4623—Processing of entitlement messages, e.g. ECM [Entitlement Control Message] or EMM [Entitlement Management Message]
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Databases & Information Systems (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
A kind of HDCP acceptor device from HDCP sender device receiving frame, the acceptor device includes frame counter, when the acceptor device is in pre-authorization mode, the frame counter is updated for each frame of content receiving from the sender device, including encryption.During pre-authorization mode, the acceptor device is not decrypted the frame of any content including encryption received.In mode after acceptor device waiting is transformed into authorization from the pre-authorization mode, the frame counter is updated for the frame including the content encrypted received by each, the acceptor device can start that the frame of any content including encryption received is decrypted in mode after the authorization.After the authorization in mode, if the frame of the content including encryption is received during the pre-authorization mode by the acceptor device, the frame counter has nonzero value.
Description
Technical field
The present invention relates to the field of synchronization of the content-encrypt engine of the HDCP on HDMI.
Background technique
The revision of the specification of high-bandwidth digital content protection (HDCP) on high-definition multimedia interface (HDMI)
Version 2.2 was issued at 2 months 2013.When establishing HDCP HDMI transmission, execute session key exchange (SKE).
HDCP system is by source device, one or more receiving devices (sink device) and/or one or more repeaters
Equipment composition.Source device is that the HDCP encrypted according to the specification of HDCP HDMI revised edition 2.2 to video/audio content is sent
Device.Receiving device is the HDCP receiver that video/audio content is decrypted according to the specification.Relay equipment is can root
Video/audio content is decrypted according to the specification HDCP repeater of simultaneously re-encrypted.Herein, we will only consider
HDCP transmitter and HDCP receiver, but identical basic principle can be applied to HDCP repeater.
At the end of the pre-authorization stage, HDCP transmitter will generate session information and be passed to HDCP receiver.In
Before sending and receiving content-data, which is programmed together with the initial value summarized in the specification of HDCP HDMI revised edition 2.2
Into content-encrypt engine.This make HDCP system move on to authorization after the stage, after authorization the stage must keep cryptosync to avoid
Link integrity problem.Cryptosync is realized when the frame counter values that the two equipment maintain like.Counter Value is opened from 0
Begin, and (shielded) frame of each encryption is incremented by.The value is used for the AES under counter mode.HDCP receiver by pair
The frame count of each encryption keeps the counting.
For the specification regulation of HDCP HDMI revised edition 2.2 before the content for sending encryption, HDCP transmitter must be close in session
Key waits 200ms after exchanging (session key exchange, SKE).This makes and the cryptosync phase on HDCP receiver
The problem of pass, minimizes.In some cases, HDCP transmitter may not meet 2.2 specification of HDCP HDMI revised edition and tight
It connects and starts to send shielded content after SKE and/or send shielded content less than the 200ms of defined.This may
Cause HDCP receiver correctly synchronous with HDCP transmitter, so as to cause link integrity problem.
Referring to Fig.1, transmitter (Tx) sends 3 three frame 101a-101c (ENC_DIS) not encrypted.Once receiving
Device (Rx) 100 programs encryption key and reaches AUTH (authorization) mode 103, and receiver 100 begins to monitoring and controls for ENC_EN
The content frame of signal 102c-102e processed.When receiving control signal after receiver 100 is transformed into AUTH mode, receiver
100 start to execute frame count 104.Keep correct frame count for ensuring that correct cryptosync is necessary.
If transmitter is not to wait for 200ms after the session key for sending encryption and is an immediately proceeding at SKE (session key friendship
Change) before, start during SKE or after SKE to send the content of encryption, then receiver 100 may it is offhand or
Ready monitoring ENC_EN=1 controls signal, and receiver 100 may not make cryptosync and thereby cannot decrypt content number
According to.Fig. 1 shows the scene, and when transmitter (Tx) starts to send the content of the encryption since frame #3 102a, there is no cutting
Licensing mode 103 is changed to, is just switched until frame #4 to licensing mode.Therefore, receiver (Rx) 100 is until receiving
To just frame counter after frame #5.
It needs just to send in encryption before the 200ms delay necessary to transmitter is standardized in HDCP HDMI 2.2
Hold, also ensures that correct cryptosync.
Summary of the invention
According to one aspect of the disclosure, a kind of method includes: at acceptor device from sender device receiving frame；With
And the frame in response to receiving the content including encryption, the acceptor device is when the acceptor device is in pre-authorization mode
Or the receiver is updated before completing the session key exchange between the acceptor device and the sender device and is filled
The internal state set.In the pre-authorization mode, the acceptor device waits authorization received to include to any
The frame of the content of encryption is decrypted.
The internal state can be frame counter, once detect that encryption makes in a frame in received frame
It can control signal, the frame counter begins to count the number of the frame as received by the acceptor device.Institute
The method of stating can also include that the frame counter is made to rise in value by the content-encrypt engine (CEE) of the acceptor device.In
When encryption key associated with the session key exchange is programmed completely by the acceptor device, the CEE can be exported
Intermediate images.After the authorization after the pre-authorization mode at the beginning of mode, the frame counter can have nonzero value.
The internal state can be the Advanced Encryption Standard engine run with counter mode, and the acceptor device is every
When the secondary frame for receiving the content including encryption, the Advanced Encryption Standard engine just makes its Counter Value rise in value.The receiver
Device can be standardized according to the high-bandwidth digital content protection (HDCP) 2.2 on high-definition multimedia interface (HDMI) from described
Sender device receives the frame.
The acceptor device can be configured to not update any internal state, receive until by the acceptor device
The frame of content including encryption.It, can be true regardless of when the sender device starts the frame that transmission includes the content of encryption
Protect correct cryptosync.
According to another aspect of the disclosure, a kind of acceptor device from sender device receiving frame is disclosed.It is described
Acceptor device includes frame counter, when the acceptor device is in pre-authorization mode and in the acceptor device
Waiting from the pre-authorization mode be transformed into authorization after mode when, for being received from the sender device including
Each frame of the content of encryption updates the frame counter, so that after the authorization in mode, if including the interior of encryption
The frame of appearance is received during the pre-authorization mode by the acceptor device, then the frame counter has nonzero value,
Described in acceptor device not to any, receive includes that the frame of content of encryption is decrypted in the pre-authorization mode,
And the acceptor device can start the frame to any content including encryption received after the authorization in mode
It is decrypted.
Detailed description of the invention
Exemplary embodiments of the present invention will be described in conjunction with following attached drawing now, in which:
Fig. 1 shows the frame that encryption is updated after authentication is complete and after transmitter has begun the content for sending and encrypting
The receiver of counting；
Fig. 2 shows the receivers for updating frame count after the frame for detecting encryption independent of verification process；
Fig. 3 shows the exemplary functions of AKE and CEE.
Specific embodiment
Referring to Fig. 2, in one embodiment, in order to ensure correct cryptosync, one detects ENC-EN control letter
Number 102a, receiver 200 just start frame count 201 before establishing SKE (or in pre-authorization or PRE-AUTH state).When
When the session key of encryption is sent receiver (Rx) by transmitter (Tx), SKE exchange occurs.The example of session key is in meeting
It talks about and negotiates between key exchange (SKE) period HDCP transmitter (Tx) and HDCP receiver (Rx) 200 and in HDCP content-encrypt
Or random, the secret key used during decryption.HDCP content includes audio-visual content (including in an encrypted form), the view
Content is listened to connect by HDCP system protection and by the interface (such as HDMI) that HDCP is protected from what HDCP transmitter was transmitted downstream to
Receiving unit (sink device) (such as HDCP receiver 200).The scene of HDCP system includes HDCP hair shown in figure 2
Send device (Tx) and HDCP receiver (Rx) 200.HDCP receiver (Rx) 200 is the interface that can be protected by one or more HDCP
The equipment that port (such as port HDMI) receives the content of encryption and it is decrypted.HDCP transmitter (Tx) is that can pass through it
The equipment of interface port (such as port HDMI) encrypting and transmitting HDCP content of one or more HDCP protections.
ENC-EN or ENC-ENC control signal is referred to as to encrypt and makes to can control signal, and indicates there is encryption in frame
Content.In Fig. 2, ENC-ENC refer to enable ENC control signal and frame in exist encryption content (term ENC-EN and
ENC-ENC is identical and is used interchangeably herein).ENC-DIS controls signal and is referred to as encryption disabling control signal,
And indicate that there is no the contents of encryption in frame.Pre-authorization or PRE-AUTH mode refer to the receiver 200 before establishing SKE
State.Once SKE is it has been established that receiver 200 shifts to authorization or AUTH mode, instruction receiver 200, which can receive, to be added
Close HDCP content.For example, certification occurs and key exchanges (Authentication and during PRE-AUTH mode
Key Exchange, AKE) and position detection, as defined in being standardized in HDCP HDMI 2.2.During AKE exchange, HDCP
Transmitter verifies the public key certificate of HDCP receiver, and exchanges master key between HDCP transmitters and receivers.In position
During inspection, HDCP transmitter is by requiring two-way time between a pair of of message to be no more than in 20ms forces at position
Hold.Frame count refers to the integer of the number for the encrypted frame that instruction has received since HDCP encryption starts.For example, according to HDCP
HDMI 2.2 is standardized, and frame count can correspond to frame number (FrameNumber) or inputCtr.At the end of authentication protocol,
Communication path is established between the transmitter (Tx) in AUTH mode and receiver (Rx) 200, with the logical of the content for encryption
Letter.
Before in terms of routinely and disclosed in the disclosure, when first encryption after immediately in SKE is enabled
(ENC_EN) when enabling HDCP encryption at for the first time, frame count or inputCtr are initialized to zero (see Fig. 1).However, according to
The disclosure, frame count are concurrently initialised and are incremented by with HDCP encryption is established.If transmitter (Tx) postpones it in 200ms
Before, but the content of encryption is sent (as controlled signal and frame by ENC_ENC before SKE, during SKE or after SKE
Presence indicated by), then because receiver (Rx) 200 is counted to frame, thus it is same that password still may be implemented
Step.The implementation meets 2.2 standard of HDCP HDMI.
When receiver 200 detects first ENC_EN (or ENC-ENC) control signal, the content of receiver 200 adds
Ciphertext engine (Content Encryption Engine, CEE) frame count of starting from scratch (202), and receiver often detects separately
One ENC_EN frame then makes frame count be incremented by 1.Content of the CEE of receiver 200 also to the encryption received from transmitter (Tx)
It is decrypted.
In the figure 2 example, receiver 200 receives first ENC-ENC control signal (102a) and frame #3, and will
Frame count is initialized as zero (202).Signal (control signal designation is controlled in company with the presence of another ENC-ENC when receiving
Encrypted content) frame #4 when, frame count increase by 1.In this example, transmitter (Tx) during PRE-AUTH mode and
SKE starts to send the content of encryption before having built up.Therefore, once transmitter (Tx) starts to send the content of encryption, even if
SKE is not yet established or although receiver still executes the movement of its pre-authorization in PRE-AUTH mode, frame has also been counted via CEE
Number.
If encryption key is not completely programmed in the CEE of receiver 200 before frame count starts to increase,
CEE can optionally export intermediate images when encryption key is just completely programmed, at this moment can be in next vertical synchronization
It is decrypted at (vertical sync, VSYNC).
Referring to Fig. 3, although in idle mode, authentication key engine (Authentication Key Engine, AKE)
300 receive certification commencing signal (AKE_Init), start to authenticate (301), and move on to authentication state (302), while CEE is from sky
Not busy mode (305) moves on to PRE-AUTH mode (307).Then SKE (303) are executed, and the CEE of receiver 200 starts from hair
The frame (308) for sending device Tx to receive encryption.When (304) are completed in certification in AKE 300, CEE also moves on to POST_AUTH mode
(309).In this embodiment, when CEE moves on to PRE_AUTH mode (307), CEE is immediately begun to frame count (306), and
When receiving frame (308) of encryption, frame count is increased by 1 (311) by CEE.
The early detection of the frame of encryption is executed, to maintain correct cryptosync.Other HDCP devices are not needed to frame
It counts, but needs correctly to maintain other states before establishing encryption key.For another example of state, counter by
Advanced Encryption Standard (Advanced Encryption Standard, AES) encrypted state machine in receiver 200 maintains.
The counter (rather than frame counter) can update before establishing SKE, and therefore maintain cryptosync.
In the present embodiment, before reaching POST_AUTH mode, content protection algorithm is directed to received each encryption
Frame start more new state (for example, frame counter or AES counter).Once key exchange is completed and CEE reaches POST_
AUTH mode, the state of engine have been just newest and have prepared that the data of input are decrypted.
Advantageously, above embodiment operates in existing standard, to mention for portable and battery-operated device
For improved power-performance.Although referring to transceiver, invention has been described, the present disclosure applies equally to receiver,
Transmitter, repeater and cipher engine.
It is described by above example, Fig. 2 to Fig. 3 is indicated to correspond to and be held by one or more control devices or computer
It goes to execute one or more algorithms of at least some instructions of above-mentioned function, movement or step.Any method described herein
Or algorithm or function may include for non-transitory machine or computer-readable instruction performed by following equipment: (a)
Manage device, (b) controller and/or (c) any other suitable processing equipment.Any algorithm, software or method disclosed herein
It can be implemented with the computer program product of one or more non-transitory tangible mediums or medium, which for example dodges
It deposits, CD-ROM, floppy disk, hard disk drive, digital versatile disc (DVD) or other storage equipment, but ordinary skill
Personnel are it should be readily understood that entire algorithm and/or its part can be executed by the device other than controller as an alternative
And/or it can be embodied in known manner in firmware or specialized hardware (for example, it can be by specific integrated circuit
(ASIC), programmable logic device (PLD), field programmable logic device (FPLD), discrete logic etc. are realized).
While there has been illustrated and described that the particular aspects and embodiment of the disclosure, but it is to be understood that the disclosure is not
It is limited to accurate construction and composition disclosed herein, but various modifications, change and modification be not in departing from appended claims
It can be not only expected in the case where the scope of the present disclosure of restriction according to foregoing description but also obviously.
Claims (6)
1. a kind of hardware receiver device, the hardware receiver device works after pre-authorization mode and authorization in mode, institute
Stating hardware receiver device includes:
Interface port, the interface port is from sender device receiving frame；
Content-encrypt engine, the content-encrypt engine have output port, and the content-encrypt engine, which receives, comes from the hair
Send the frame of the content comprising encryption of device device；And
Frame counter, the frame counter have frame counter values and input port, and the input port is connected to the content
The output port of crypto engine, for being received during the pre-authorization mode from the sender device, tested
Each of the frame including control signal frame is measured, so that the frame counter values is rised in value by the content-encrypt engine, makes
It obtains after the authorization in mode, if the frame received during the pre-authorization mode includes the content of encryption,
The frame counter values are non-zeros, wherein the control signal designation has the content of encryption in the frame received；
Wherein, in mode after waiting is transformed into the authorization from the pre-authorization mode, the hardware receiver device is in institute
It states in pre-authorization mode and the frame received is not decrypted, wherein the pre-authorization mode is the hardware receiver
The state of device completed with the sender device before session key exchange, and mode is the hardware after the authorization
The state of acceptor device completed after the session key exchange, and
Wherein, the hardware receiver device realizes that the sender device connects with the hardware using the frame counter values
Receive the cryptosync between device device.
2. hardware receiver device according to claim 1, in which:
Before the frame to the content including the encryption received is decrypted, the content-encrypt engine waits institute
State the completion of session key exchange.
3. hardware receiver device according to claim 1, wherein in encryption associated with the session key exchange
When key is programmed, the content-encrypt engine exports intermediate images.
4. hardware receiver device according to claim 1, wherein the frame counter with counter mode by being run
Advanced Encryption Standard engine implementation, whenever a frame in the frame received include encryption content when, it is described advanced
Encryption standard engine just makes the frame counter values rise in value.
5. hardware receiver device according to claim 1, wherein the hardware receiver device is more according to fine definition
High-bandwidth digital content protection in the specification of media interface 2.2 receives the frame from the sender device.
6. hardware receiver device according to claim 1, wherein until the frame in the frame received includes connecing
The content of the encryption received, the frame counter just start to rise in value.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/IB2014/060718 WO2015159121A1 (en) | 2014-04-14 | 2014-04-14 | Early content engine receiver synchronization |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN106464491A CN106464491A (en) | 2017-02-22 |
| CN106464491B true CN106464491B (en) | 2019-11-19 |
Family
ID=54323535
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201480079283.1A Active CN106464491B (en) | 2014-04-14 | 2014-04-14 | Hardware receiver device |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN106464491B (en) |
| WO (1) | WO2015159121A1 (en) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101507271A (en) * | 2005-08-29 | 2009-08-12 | 索尼株式会社 | Control 3 signal synthesis |
| CN102273218A (en) * | 2009-01-09 | 2011-12-07 | 晶像股份有限公司 | Method, apparatus and system for pre-authentication and keep-authentication of content protected ports |
| CN102771136A (en) * | 2010-02-25 | 2012-11-07 | 晶像股份有限公司 | Video frame synchronization |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2013129785A1 (en) * | 2012-02-29 | 2013-09-06 | Samsung Electronics Co., Ltd. | Data transmitter, data receiver, data transceiving system, data transmitting method, data receiving method, and data transceiving method |
| US9578319B2 (en) * | 2012-03-02 | 2017-02-21 | Broadcom Corporation | Transmission variable delay and jitter indication |
-
2014
- 2014-04-14 WO PCT/IB2014/060718 patent/WO2015159121A1/en active Application Filing
- 2014-04-14 CN CN201480079283.1A patent/CN106464491B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101507271A (en) * | 2005-08-29 | 2009-08-12 | 索尼株式会社 | Control 3 signal synthesis |
| CN102273218A (en) * | 2009-01-09 | 2011-12-07 | 晶像股份有限公司 | Method, apparatus and system for pre-authentication and keep-authentication of content protected ports |
| CN102771136A (en) * | 2010-02-25 | 2012-11-07 | 晶像股份有限公司 | Video frame synchronization |
Non-Patent Citations (3)
| Title |
|---|
| "Decrypting HDCP-protected Video Streams Using Reconfigurable Hardware";Benno Lomb 等;《2011 International Conference on Reconfigurable Computing and FPGAs》;20111202;第249-254页 * |
| "HDMI与HDCP技术分析及应用";周咸春 等;《中国科技信息》;20070601(第11期);第150-153页 * |
| "高带宽数字内容保护技术接收端的研究与设计";蒋特林 等;《电子科技》;20111115;第24卷(第11期);第103-105页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN106464491A (en) | 2017-02-22 |
| WO2015159121A1 (en) | 2015-10-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9509669B2 (en) | Efficient routing of streams encrypted using point-to-point authentication protocol | |
| CN102273218B (en) | Method, apparatus and system for pre-authentication and keep-authentication of content protected ports | |
| US8316241B2 (en) | Data transmitting apparatus, data receiving apparatus, data transmitting method, and data receiving method | |
| US11212671B2 (en) | Method and system for securing communication links using enhanced authentication | |
| WO2014074127A1 (en) | An improved implementation of robust and secure content protection in a system-on-a-chip apparatus | |
| MX2017009553A (en) | Authentication method, notification method, source device and sink device. | |
| EP3361737A1 (en) | Protecting media content | |
| KR102616337B1 (en) | Smooth transitions for content type changes in streaming content | |
| CN105635759A (en) | Output content protection method and condition receiving module | |
| KR102032234B1 (en) | Keep the encryption process synchronized across devices by sending frame numbers | |
| CN106464491B (en) | Hardware receiver device | |
| US9571473B2 (en) | Early content engine receiver synchronization | |
| WO2018226295A1 (en) | Avoiding link integrity failures on displayport during hcdp 2.2 by using sink side optimizations | |
| JP2010239557A (en) | Video transmission device, authentication method, authentication program, and video transmission system | |
| CN105306205B (en) | Decryption engine and decryption method | |
| WO2024077857A1 (en) | Data transmission method and apparatus, and device and storage medium | |
| KR102029550B1 (en) | Design of hdcp for displayport | |
| TWI547134B (en) | Decryption engine and decryption method | |
| CN105119718B (en) | A kind of method and its system for generating the key with service life |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |