Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
High-bandwidth Digital Content Protection
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
{{Short description|Digital copy protection}} {{Redirect-distinguish|HDCP|DHCP}} {{Use dmy dates|date=November 2020}} {{Use American English|date = March 2019}} '''High-bandwidth Digital Content Protection''' ('''HDCP''') is a form of digital [[copy protection]] developed by [[Intel|Intel Corporation]]<ref>{{cite web| title = Digital Content Protection - About DCP | url = http://www.digital-cp.com/about_dcp}}</ref> to prevent copying of digital audio and video content as it travels across connections. Types of connections include [[DisplayPort]] (DP), [[Digital Visual Interface]] (DVI), and [[High-Definition Multimedia Interface]] (HDMI), as well as less popular or now deprecated protocols like [[Gigabit Video Interface]] (GVIF) and [[Unified Display Interface]] (UDI). The system is meant to stop HDCP-encrypted content from being played on unauthorized devices or devices which have been modified to copy HDCP content.<ref>HDCP specification 1.3. Page 31 0x15, Page 35</ref><ref>{{cite web|title=HD DVD Glossary|url=http://www.hddvd-faq.com/glossary.asp}} 080509 hddvd-faq.com</ref> Before sending data, a transmitting device checks that the receiver is authorized to receive it. If so, the transmitter encrypts the data to prevent eavesdropping as it flows to the receiver.<ref name=autogenerated1 /> In order to make a device that plays HDCP-enabled content, the manufacturer must obtain a license for the patent from [[Intel]] subsidiary Digital Content Protection LLC, pay an annual fee, and submit to various conditions.<ref name=HDCP_1.3>{{cite web |url=http://www.digital-cp.com/files/static_page_files/8006F925-129D-4C12-C87899B5A76EF5C3/HDCP_Specification%20Rev1_3.pdf |title=HDCP v1.3 specification |work=Digital Content Protection |date=21 December 2006 |access-date=8 May 2008 |url-status=dead |archive-url=https://web.archive.org/web/20080920192936/http://www.digital-cp.com/files/static_page_files/8006F925-129D-4C12-C87899B5A76EF5C3/HDCP_Specification%20Rev1_3.pdf |archive-date=20 September 2008 }}</ref><ref>{{cite web|url=http://www.digital-cp.com/home |title=Digital Content Protection LLC |access-date=24 January 2008 |url-status=dead |archive-url=https://web.archive.org/web/20080202215640/http://www.digital-cp.com/home |archive-date=2 February 2008 }}</ref><ref name=HDCP_clique>{{cite news|title=HDCP License Agreement |date=16 January 2008 |publisher=Digital Content Protection, LLC. |url=http://www.digital-cp.com/files/static_page_files/D6724AFD-9B02-A253-D8D2FE5B1A10F7F7/HDCP_License_Agreement_082207.pdf |access-date=24 January 2008 |url-status=dead |archive-url=https://web.archive.org/web/20090419204233/http://www.digital-cp.com/files/static_page_files/D6724AFD-9B02-A253-D8D2FE5B1A10F7F7/HDCP_License_Agreement_082207.pdf |archive-date=19 April 2009 }}</ref> For example, the device cannot be designed to copy; it must "frustrate attempts to defeat the content protection requirements";<ref name=HDCP_clique/> it must not transmit high definition protected video to non-HDCP receivers; and DVD-Audio works can be played only at [[Compact Disc|CD]]-audio quality<ref name=HDCP_clique/> by non-HDCP digital audio outputs (analog audio outputs have no quality limits). If the device has a feature like [[Intel_Management_Engine#Disabling_the_ME|Intel Management Engine]] disabled, HDCP will not work. Cryptanalysis researchers demonstrated flaws in HDCP as early as 2001. In September 2010, an HDCP master key that allows for the generation of valid device keys was released to the public, rendering the key revocation feature of HDCP useless.<ref name="Lawler">{{cite web |url=https://www.engadget.com/2010/09/14/hdcp-master-key-supposedly-released-unlocks-hdtv-copy-protect/ |title=HDCP 'master key' supposedly released, unlocks HDTV copy protection permanently |first=Richard |last=Lawler |date=14 September 2010 |publisher=Engadget |access-date=14 September 2010}}</ref><ref>{{cite news|author=Peter Bright|title=Intel confirms HDCP key is real, can now be broken at will|publisher=[[Ars Technica]]|date=17 September 2010|access-date=17 September 2010|url=https://arstechnica.com/tech-policy/news/2010/09/intel-confirms-the-hdcp-key-is-real-can-now-be-broken-at-will.ars}}</ref> Intel has confirmed that the crack is real,<ref>{{Cite web |last=Staff |first=Ars |date=2010-09-17 |title=Intel confirms HDCP key is real, can now be broken at will |url=https://arstechnica.com/tech-policy/news/2010/09/intel-confirms-the-hdcp-key-is-real-can-now-be-broken-at-will.ars |access-date=2022-06-12 |website=[[Ars Technica]] |language=en-us}}</ref> and believes the master key was [[Reverse engineering|reverse engineered]] rather than leaked.<ref name="w2" /> In practical terms, the impact of the crack has been described as "the digital equivalent of [[Analog hole|pointing a video camera at the TV]]", and of limited importance for consumers because the encryption of high-definition discs has been [[AACS encryption key controversy|attacked directly]], with the loss of interactive features like menus.<ref>{{Cite web|url=https://www.cnet.com/news/privacy/hdcp-antipiracy-leak-opens-doors-for-black-boxes/|title=HDCP antipiracy leak opens doors for black boxes|website=CNET}}</ref> Intel threatened to sue anyone producing an unlicensed device.<ref name="w2">{{Cite magazine |date=2010-09-17 |title=Intel Threatens to Sue Anyone Who Uses HDCP Crack |magazine=[[Wired (magazine)|Wired]] |last=Kravets |first=David |url=https://www.wired.com/threatlevel/2010/09/intel-threatens-consumers/ |access-date=2025-02-03 |archive-url=https://web.archive.org/web/20110325014547/https://www.wired.com/threatlevel/2010/09/intel-threatens-consumers/ |archive-date=2011-03-25}}</ref> == Specification == HDCP uses three systems:<ref name=HDCP_1.3 /> # Authentication prevents non-licensed devices from receiving content. # Encryption of the data sent over DisplayPort, DVI, HDMI, GVIF, or UDI interfaces prevents [[eavesdropping]] of information and [[man-in-the-middle attack]]s. # Key revocation prevents devices that have been compromised and cloned from receiving data. Each HDCP-capable device has a unique set of 40 56-bit keys. Failure to keep them secret violates the license agreement. For each set of values, a special private key called a [[Key selection vector|KSV]] (Key Selection Vector) is created. Each KSV consists of 40 bits (one bit for each HDCP key), with 20 bits set to 0 and 20 bits set to 1. During authentication, the parties exchange their KSVs under a procedure called [[Blom's scheme]]. Each device adds its own secret keys together (using [[Signedness|unsigned]] addition [[modular arithmetic|modulo]] 2<sup>56</sup>) according to a KSV received from another device. Depending on the order of the bits set to 1 in the KSV, a corresponding secret key is used or ignored in the addition. The generation of keys and KSVs gives both devices the same 56-bit number, which is later used to encrypt data. Encryption is done by a [[stream cipher]]. Each decoded [[pixel]] is encrypted by applying an [[Exclusive or|XOR]] operation with a 24-bit number produced by a generator. The HDCP specifications ensure constant updating of keys after each encoded frame. If a particular set of keys is compromised, their corresponding KSV is added to a revocation list burned onto new discs in the DVD and Blu-ray formats. (The lists are signed with a [[Digital Signature Algorithm|DSA]] digital signature, which is meant to keep malicious users from revoking legitimate devices.) During authentication, the transmitting device looks for the receiver's KSV on the list, and if it is there, will not send the decrypted work to the revoked device. == Uses == [[File:Apple TV, 1st generation - mainboard - Silicon Image SiI1930CTU-3215.jpg|thumb|An HDCP transmitter chip by [[Silicon Image]] in an [[Apple TV]] device]] HDCP devices are generally divided into three categories: ;Source: The source sends the content to be displayed. Examples include set-top boxes, [[DVD]], [[HD DVD]] and [[Blu-ray Disc]] players, and computer video cards. A source has only an HDCP/HDMI transmitter.<ref name=autogenerated1 /> ;Sink: The sink renders the content for display so it can be viewed. Examples include TVs and digital projectors. A sink has one or more HDCP/HDMI receivers.<ref name=autogenerated1 /> ;Repeater: A repeater accepts content, decrypts it, then re-encrypts and retransmits the data. It may perform some signal processing, such as upconverting video into a higher-resolution format, or splitting out the audio portion of the signal. Repeaters have HDMI inputs and outputs. Examples include home theater audio-visual receivers that separate and amplify the audio signal, while re-transmitting the video for display on a TV. A repeater could also simply send the input data stream to multiple outputs for simultaneous display on several screens.<ref name=autogenerated1 /> Each device may contain one or more HDCP transmitters and/or receivers. (A single transmitter or receiver chip may combine HDCP and HDMI functionality.)<ref name=autogenerated1>{{cite web|date=22 July 2008 |title=HDCP deciphered: white paper |publisher=DCP, LLC |url=http://www.digital-cp.com/files/documents/04A897FD-FEF1-0EEE-CDBB649127F79525/HDCP_deciphered_070808.pdf |url-status=unfit |archive-url=https://web.archive.org/web/20080920191718/http://www.digital-cp.com/files/documents/04A897FD-FEF1-0EEE-CDBB649127F79525/HDCP_deciphered_070808.pdf |archive-date=20 September 2008 }}</ref> In the [[United States]], the Federal Communications Commission (FCC) approved HDCP as a "Digital Output Protection Technology" on 4 August 2004.<ref>{{cite press release |date=4 August 2004 |title=FCC Approves Digital Output Protection Technologies and Recording Method Certifications |publisher=[[Federal Communications Commission]] |url=http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-250532A1.pdf |access-date=28 December 2006 |archive-date=17 October 2011 |archive-url=https://web.archive.org/web/20111017035106/http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-250532A1.pdf |url-status=dead }}</ref> The FCC's [[Broadcast flag]] regulations, which were struck down by the [[United States Court of Appeals for the District of Columbia Circuit]], would have required [[Digital rights management|DRM]] technologies on all digital outputs from HDTV signal demodulators. [[United States Congress|Congress]] is still considering{{when|date=July 2014}} legislation that would implement something similar to the Broadcast Flag.{{citation needed|date=July 2014}} The HDCP standard is more restrictive than the FCC's Digital Output Protection Technology requirement. HDCP bans compliant products from converting HDCP-restricted content to full-resolution analog form, presumably in an attempt to reduce the size of the [[analog hole]].{{weasel inline|date=February 2015}} On 19 January 2005, the European Information, Communications, and Consumer Electronics Technology Industry Associations ([[EICTA]]) announced that HDCP is a required component of the European "[[HD ready]]" label.<ref>{{cite press release |date=19 January 2005 |title=EICTA announces "Conditions for High Definition Labelling <!-- sic! --> of Display Devices |publisher=[[EICTA]] |url=http://www.eicta.org/fileadmin/user_upload/document/document1160753216.pdf |access-date=28 December 2006 |archive-url=https://web.archive.org/web/20070114175730/http://www.eicta.org/fileadmin/user_upload/document/document1160753216.pdf |archive-date=14 January 2007 |url-status=dead }}</ref> Microsoft [[Windows Vista]] and [[Windows 7]] both use HDCP in computer graphics cards and monitors.<ref>{{Cite web|url=http://www.microsoft.com/whdc/device/media/output_protect.mspx|title=Output Content Protection and Windows Vista<!-- Bot generated title -->|website=[[Microsoft]] }}</ref><ref>{{Cite web |url=https://www.engadget.com/entry/1234000143050582/ |title=The Clicker: Microsoft's OPM for the masses – Engadget<!-- Bot generated title --> |access-date=29 August 2017 |archive-url=https://web.archive.org/web/20080726070508/http://www.engadget.com/entry/1234000143050582/ |archive-date=26 July 2008 |url-status=dead }}</ref> == Circumvention == HDCP strippers decrypt the HDCP stream and transmit an unencrypted HDMI video signal so it will work in a non-HDCP display. It is currently{{when|date=February 2015}} unclear whether such devices would remain working if the HDCP licensing body issued key-revocation lists, which may be installed via new media (e.g. newer [[Blu-ray Disc]]s) played-back by another device (e.g. a Blu-ray Disc player) connected to it.<ref>{{cite web |author=Ryan Block |date=21 July 2005 |title=The Clicker: HDCP's Shiny Red Button |publisher=[[Engadget]] |url=https://www.engadget.com/2005/07/21/the-clicker-hdcps-shiny-red-button |access-date=28 December 2006 }}</ref> === Cryptanalysis === In 2001, Scott Crosby of [[Carnegie Mellon University]] wrote a paper with [[Ian Goldberg]], Robert Johnson, Dawn Song, and [[David A. Wagner|David Wagner]] called "A Cryptanalysis of the High-bandwidth Digital Content Protection System", and presented it at ACM-CCS8 DRM Workshop on 5 November.<ref>{{cite conference|first1=Scott |last1=Crosby |first2=Ian |last2=Goldberg |first3=Robert |last3=Johnson |first4=Dawn |last4=Song |first5=David |last5=Wagner |date=5 November 2001 |title=A Cryptanalysis of the High-bandwidth Digital Content Protection System |conference=[[Association for Computing Machinery|ACM]]-CSS8 DRM Workshop |url=http://web.mit.edu/skendig/Public/hdcppaper.pdf |access-date=3 March 2025 |doi=10.1007/3-540-47870-1_12 }}</ref> The authors concluded that HDCP's linear key exchange is a fundamental weakness, and discussed ways to: * Eavesdrop on any data. * Clone any device with only its public key. * Avoid any blacklist on devices. * Create new device key vectors. * In aggregate, usurp the authority completely. They also said the Blom's scheme key swap could be broken by a so-called ''conspiracy attack'': obtaining the keys of at least 40 devices and reconstructing the secret symmetrical master matrix that was used to compute them. Around the same time, [[Niels Ferguson]] independently claimed to have broken the HDCP scheme, but he did not publish his research, citing legal concerns arising from the controversial [[Digital Millennium Copyright Act]].<ref>Niels Ferguson, [https://web.archive.org/web/20120220014712/http://www.macfergus.com/niels/dmca/cia.html DMCA Censorship], 15 August 2001</ref> In November 2011 Professor Tim Güneysu of [[Ruhr-Universität Bochum]] revealed he had broken the HDCP 1.3 encryption standard. === Master key release === On 14 September 2010, [[Engadget]] reported the release of a possible genuine HDCP master key which can create device keys that can authenticate with other HDCP compliant devices without obtaining valid keys from The Digital Content Protection LLC. This master key would neutralize the key revocation feature of HDCP, because new keys can be created when old ones are revoked.<ref name="Lawler"/> Since the master key is known, it follows that an unlicensed HDCP decoding device could simply use the master key to dynamically generate new keys on the fly, making revocation impossible. It was not immediately clear who discovered the key or how they discovered it, though the discovery was announced via a [[Twitter]] update which linked to a [[Pastebin]] snippet containing the key and instructions on how to use it. Engadget said the attacker may have used the method proposed by Crosby in 2001 to retrieve the master key, although they cited a different researcher. On 16 September, Intel confirmed that the code had been cracked.<ref>{{cite news| url=http://www.foxnews.com/scitech/2010/09/16/intel-confirms-hdtv-code-cracked/ | archive-url=https://web.archive.org/web/20100917184417/http://www.foxnews.com/scitech/2010/09/16/intel-confirms-hdtv-code-cracked/ | url-status=dead | archive-date=17 September 2010 | work=Fox News | title=HDTV Code Crack Is Real, Intel Confirms | date=16 September 2010}}</ref><ref>{{Cite web|url=https://www.tomshardware.com/news/hdcp-master-key-copy-protection,11311.html|title=Intel Confirms That HDCP Master Key is Cracked|author1=Marcus Yam|date=18 September 2010|website=Tom's Hardware}}</ref> Intel has threatened legal action against anyone producing hardware to circumvent the HDCP, possibly under the [[Digital Millennium Copyright Act]].<ref name=w2/> <!-- TO WOULD-BE EDITORS: Please do not add the text of the master key (a possible violation of [[WP:COPYVIO]]). Including a link to the key is disputed as well. See talk page. --> === HDCP v2.2, v2.1 and v2.0 breach === In August 2012 version 2.1 was proved to be broken.<ref name="Green12">{{cite web | url = http://blog.cryptographyengineering.com/2012/08/reposted-cryptanalysis-of-hdcp-v2.html | title = Reposted: A cryptanalysis of HDCP v2.1 | first = Matthew | last = Green | date = 27 August 2012 | work = A Few Thoughts on Cryptographic Engineering }}</ref> The attack used the fact that the pairing process sends the ''Km'' key obfuscated with an [[XOR]]. That makes the encryptor (receiver) <!-- I don't see how the receiver could also be the encryptor, but OK --> unaware of whether it encrypts or decrypts the key. Further, the input parameters for the XOR and the AES above it are fixed from the receiver side, meaning the transmitter can enforce repeating the same operation. Such a setting allows an attacker to monitor the pairing protocol, repeat it with a small change and extract the ''Km'' key. The small change is to pick the "random" key to be the encrypted key from the previous flow. Now, the attacker runs the protocol and in its pairing message it gets ''E(E(Km))''. Since ''E()'' is based on XOR it undoes itself, thus exposing the ''Km'' of the legitimate device. V2.2 was released to fix that weakness by adding randomness provided by the receiver side. However the transmitter in V2.2 must not support receivers of V2.1 or V2.0 in order to avoid this attack. Hence a new erratum was released to redefine the field called "Type" to prevent backward compatibility with versions below 2.2. The "Type" flag should be requested by the content's usage rules (i.e. via the DRM or CAS that opened the content).<ref name="hdcp22">{{cite web|url=https://www.digital-cp.com/sites/default/files/specifications/HDCP%20Interface%20Independent%20Adaptation%20Specification%20Rev2_2_FINAL.pdf|title=High-bandwidth Digital Content Protection System: Mapping HDCP to HDMI (Revision 2.2)|date=13 February 2013|publisher=Digital Content Protection LLC}}</ref> In August 2015, version 2.2 was rumored to be broken. An episode of AMC's series ''[[Breaking Bad]]'' was leaked to the Internet in UHD format; its metadata indicated it was an ''HDMI cap'', meaning it was captured through HDMI interface that removed HDCP 2.2 protection.<ref>{{cite web | title = First Netflix 4K Content Leaks to Torrent Sites | url = https://torrentfreak.com/first-netflix-4k-content-leaks-to-torrent-sites-150828/ | date = 28 August 2015 | publisher=Torrentfreak | first = Ernesto | last = van der Sar }}</ref><ref>{{cite news |work=[[The Verge]] | title = Netflix's 4K video reportedly cracked, Breaking Bad episode posted online | url = https://www.theverge.com/2015/8/28/9222337/piracy-netflix-breaking-bad-4k-episode | date = 28 August 2015 | first = Adi | last = Robertson }}</ref> On 4 November 2015, Chinese company LegendSky Tech Co., already known for their other HDCP rippers/splitters under the HDFury brand, released the HDFury Integral, a device that can remove HDCP 2.2 from HDCP-enabled UHD works.<ref>{{cite web|title=HDfury launches yet another path breaking device – the HDCP Doctor, HDfury Integral|url=https://www.hdfury.com/11159/|website=HDFury.com|publisher=HDFury|access-date=7 January 2016|archive-url=https://web.archive.org/web/20160115002430/http://www.hdfury.com/11159/|archive-date=15 January 2016|url-status=dead}}</ref> On 31 December 2015, [[Warner Bros]] and Digital Content Protection, LLC (DCP, the owners of HDCP) filed a lawsuit against LegendSky.<ref>{{cite web|title=Lawsuit against Legendsky (PDF)|url=https://archive.org/details/gov.uscourts.nysd.451763|access-date=7 January 2016}}</ref><ref>{{cite web|last1=Mullin|first1=Joe|title=Warner Bros. sues "HD Fury" over boxes that can copy 4k video|url=https://arstechnica.com/tech-policy/2016/01/warner-bros-sues-hd-fury-over-boxes-that-can-copy-4k-video/|website=Ars Technica|date=4 January 2016 |access-date=7 January 2016}}</ref> Nevertheless, the lawsuit was ultimately dropped after LegendSky argued that the device did not "strip" HDCP content protection but rather downgraded it to an older version, a measure which is explicitly permitted in DCP's licensing manual.<ref>{{Cite news|url=https://torrentfreak.com/4k-content-protection-stripper-beats-warner-bros-in-court-1605xx/|title=4K Content Protection "Stripper" Beats Warner Bros in Court|last=Van der Sar|first=Ernesto|date=6 May 2016|work=TorrentFreak|access-date=6 June 2017}}</ref> == Problems == HDCP can cause problems for users who want to connect multiple screens to a device; for example, a bar with several televisions connected to one satellite receiver or when a user has a closed laptop and uses an external display as the only monitor. HDCP devices can create multiple keys, allowing each screen to operate, but the number varies from device to device; e.g., a Dish or Sky satellite receiver can generate 16 keys.<ref>{{ cite web | url = http://www.crestron.com/downloads/pdf/misc/third_party_hdcp_limits.pdf | title = Device List as of 1/7/2010 | publisher = Crestron }}</ref> The technology sometimes causes [[Handshake (computing)|handshaking]] problems where devices cannot establish a connection, especially with older high-definition displays.<ref>{{cite web | url = http://www.popularmechanics.com/blogs/technology_news/4212233.html | title = PS3 Blinking Mystery Deepens—Westinghouse: "Our TVs Not the Problem" | first = Emily | last = Masamitsu | work = Popular Mechanics | date = 23 January 2007 | archive-url = https://web.archive.org/web/20070206224544/http://www.popularmechanics.com/blogs/technology_news/4212233.html | archive-date = 6 February 2007 }}</ref><ref>{{cite web | url = http://www.avrev.com/news/1105/10.hdcp.html | title = HDCP "Handshake" A Big Problem For Many Legacy DVI-Based HDTVs | work = AVRev.com | first = Scott | last = Selter | date = 10 November 2005 | access-date = 8 March 2008 | archive-url = https://web.archive.org/web/20091212070208/http://www.avrev.com/news/1105/10.hdcp.html | archive-date = 12 December 2009 | url-status = dead }}</ref><ref>{{cite web | url = http://www.eetimes.com/design/communications-design/4013366/HDMI-DVI-HDCP-handshake-problems--how-to-avoid-them | work = EETimes | title = HDMI/DVI HDCP handshake problems & how to avoid them | first = Mark | last = Stockfisch | date = 4 November 2007 }}</ref> [[Edward Felten]] wrote "the main practical effect of HDCP has been to create one more way in which your electronics could fail to work properly with your TV," and concluded in the aftermath of the master key fiasco that HDCP has been "less a security system than a tool for shaping the consumer electronics market."<ref>{{cite web | url = http://www.freedom-to-tinker.com/blog/felten/understanding-hdcp-master-key-leak | title = Understanding the HDCP Master Key Leak | date = 11 September 2010 | first = Ed | last = Felten }}</ref> Additional issues arise when interactive media (i.e. video games) suffer from [[Display lag|control latency]], because it requires additional processing for encoding/decoding. Various everyday usage situations, such as live streaming or capture of game play, are also adversely affected.<ref>{{cite web | url = http://gaming.stackexchange.com/questions/13704/how-do-you-capture-video-of-your-ps3-gameplay | title = How do you capture video of your PS3 gameplay | work = Arqade | publisher = Stack Exchange | date = 1 January 2011 }}</ref> There is also the problem that all Apple laptop products, presumably in order to reduce switching time, when confronted with an HDCP-compliant sink device, automatically enable HDCP encryption from the HDMI / Mini DisplayPort / USB-C connector port. This is a problem if the user wishes to use recording or videoconferencing facilities further down the chain, because these devices most often do not decrypt HDCP-enabled content (since HDCP is meant to avoid direct copying of content, and such devices could conceivably do exactly that). This applies even if the output is not HDCP-requiring content, like a [[PowerPoint]] presentation or merely the device's UI.<ref>{{cite web | url = https://support.apple.com/en-us/HT204388 | title = Frequently asked questions about using HDMI with Mac computers - Apple Support | publisher = Apple | date = 22 March 2017 }}</ref> Some sink devices have the ability to disable their HDCP reporting entirely, however, preventing this issue from blocking content to videoconferencing or recording. However, HDCP content will then refuse to play on many source devices if this is disabled while the sink device is connected.<ref>{{cite web | url = http://www.crestron.com/downloads/pdf/product_engineering_specifications/hdcp_whitepaper_crestron.pdf | title = HDCP White Paper: How DigitalMedia(TM) Switchers Handle HDCP | publisher = Crestron}}</ref> When connecting a HDCP 2.2 source device through compatible distribution to a video wall made of multiple legacy displays the ability to display an image cannot be guaranteed.<ref>{{cite web | url = http://www.extron.com/download/files/whitepaper/hdcp_2_2_wp.pdf | title = Introduction to HDCP2.2 | publisher = Extron | date = 8 September 2015 }}</ref> == Versions == {| class="wikitable" |- ! HDCP revision || Release Date || Notes |- | 1.0 || 17 February 2000 || Supports DVI only |- | 1.1 || 9 June 2003 || Supports DVI, HDMI |- | 1.2 || 13 June 2006 || Supports DVI, HDMI |- | 1.3 || 21 Dec 2006|| Supports DVI, HDMI, [[DisplayPort|DP]], [[Gigabit Video Interface|GVIF]], [[Unified Display Interface|UDI]] |- | 1.4 || 8 July 2009 || |- | 2.0 IIA || 23 Oct 2008|| * Interface Independent Adaptation, any IP-based interface * Compressed or uncompressed video (only specified for compressed over PES though) |- | 2.1 IIA || 18 July 2011 || * New mechanism to manage Type 1 content. Type 1 is a flag preventing content from going to v1.x HDCP. It is assumed that UHD content will require that. * Resolves addition of devices to the HDMI tree without a full tree re-authentication by allowing ReceiverID_List to be asynchronous |- | 2.2 IIA || 16 October 2012 || * Addresses a breach described above, as well as other flaws in Locality Check * Type 1 extended to preventing content from going to v2.1, 2.0 and v1.x as they all have weaknesses |- | 2.2 for HDMI || 13 February 2013 | rowspan="2" | * This spec is not bound to backward compatibility to v2.0 and v2.1 hence makes it a clean version of v2.2 |- | 2.2 for [[Mobile High-Definition Link|MHL]]|| 11 September 2013 |- | 2.3 for HDMI || 28 February 2018 || |} == HDCP v2.x == The 2.x version of HDCP is not a continuation of HDCPv1, and is rather a completely different link protection. Version 2.x employs industry-standard encryption algorithms, such as 128-bit [[Advanced Encryption Standard|AES]] with 3072 or 1024-bit [[RSA (cryptosystem)|RSA]] public key and 256-bit [[HMAC-SHA256]] hash function.<ref name="hdcp22"/> While all of the HDCP v1.x specifications support backward compatibility to previous versions of the specification, HDCPv2 devices may interface with HDCPv1 hardware only by natively supporting HDCPv1, or by using a dedicated converter device. This means that HDCPv2 is only applicable to new technologies. It has been selected for the [[WirelessHD]] and [[Miracast]] (formerly WiFi Display) standards.<ref>{{cite web|title=WirelessHD 1.1 Specification Summary|url=http://www.wirelesshd.org/about/specification-summary/|website=WirelessHD|access-date=18 April 2017|archive-date=19 April 2017|archive-url=https://web.archive.org/web/20170419110903/http://www.wirelesshd.org/about/specification-summary/|url-status=dead}}</ref><ref>{{cite web|title=Technical Note Wi-Fi CERTIFIED Miracast™ HDCP Interoperability Issue: HDCP 2.2 Protocol Descriptor|url=https://www.wi-fi.org/download.php?file=/sites/default/files/private/Miracast_HDCP_Tech_Note_v1%200_0.pdf|website=WiFi Alliance|access-date=18 April 2017}}</ref> HDCP 2.x features a new authentication protocol, and a locality check to ensure the receiver is relatively close (it must respond to the locality check within 7 ms on a normal DVI/HDMI link).<ref name="hdcp22"/> Version 2.1 of the specification was cryptanalyzed and found to have several flaws, including the ability to recover the session key.<ref name="Green12"/> There are still a few commonalities between HDCP v2 and v1. # Both are under DCP LLC authority. # They share the same license agreement, compliance rules and robustness rules. # They share the same revocation system and same device ID formats. == See also == * [[HDCP repeater bit]] * [[Digital Transmission Content Protection]] * [[Digital rights management]] * [[Encrypted Media Extensions]] * [[Defective by Design]] * [[Trusted Computing]] == References == {{reflist|30em}} == External links == * {{Official website|https://www.digital-cp.com/}} {{Intel technology}} {{broadcast encryption}} {{DEFAULTSORT:High-Bandwidth Digital Content Protection}} [[Category:Audiovisual introductions in 2000]] [[Category:Computer-related introductions in 2000]] [[Category:Broken stream ciphers]] [[Category:Copy protection]] [[Category:High-definition television]] [[Category:Intel products]] [[Category:Digital rights management standards]]
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)
Pages transcluded onto the current version of this page
(
help
)
:
Template:Broadcast encryption
(
edit
)
Template:Citation needed
(
edit
)
Template:Cite conference
(
edit
)
Template:Cite magazine
(
edit
)
Template:Cite news
(
edit
)
Template:Cite press release
(
edit
)
Template:Cite web
(
edit
)
Template:Intel technology
(
edit
)
Template:Official website
(
edit
)
Template:Redirect-distinguish
(
edit
)
Template:Reflist
(
edit
)
Template:Short description
(
edit
)
Template:Use American English
(
edit
)
Template:Use dmy dates
(
edit
)
Template:Weasel inline
(
edit
)
Template:When
(
edit
)