biss
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
biss [2017/01/26 11:00] – [BISS E] walkeradmin | biss [2017/01/26 11:23] – [BISS] walkeradmin | ||
---|---|---|---|
Line 3: | Line 3: | ||
\\ | \\ | ||
\\ | \\ | ||
- | |||
- | ---- | ||
BISS is supported using an optional card that sits on the encoder motherboard. If the option is fitted and correctly licensed, you will be able to encrypt your content using either BISS mode 1 or BISS E. | BISS is supported using an optional card that sits on the encoder motherboard. If the option is fitted and correctly licensed, you will be able to encrypt your content using either BISS mode 1 or BISS E. | ||
Line 11: | Line 9: | ||
---- | ---- | ||
+ | ==== Document and Software Download ==== | ||
+ | \\ | ||
+ | Download this document and the BISS SW {{ : | ||
+ | \\ | ||
+ | \\ | ||
+ | |||
+ | ---- | ||
+ | |||
==== BISS Mode 1 ==== | ==== BISS Mode 1 ==== | ||
\\ | \\ | ||
Line 44: | Line 50: | ||
\\ | \\ | ||
\\ | \\ | ||
- | {{ : | + | {{ : |
\\ | \\ | ||
**The CSW, ID and ESW are all linked by a BISS E algorithm. If you know any two, you can derive the third. ** | **The CSW, ID and ESW are all linked by a BISS E algorithm. If you know any two, you can derive the third. ** | ||
+ | \\ | ||
+ | \\ | ||
+ | {{ : | ||
+ | \\ | ||
+ | **When generating BISS-E keys for distribution to clients, you will know the CSW and the ID for each receiver. A software application then generates the ESW. ** | ||
+ | \\ | ||
+ | \\ | ||
+ | {{ : | ||
+ | \\ | ||
+ | **In the receiver, you must enter the ESW. The ID will already be burned into the receiver and in most cases will only be known to the system administrator generating the keys. The ESW and ID combination will be used by the receiver to internally derive the CSW. The receiver will only de-crypt correctly if the derived CSW is correct and matches the CSW used in the encoder. In most cases you cannot read the ID back from the receiver and so a receiver operator will not be aware of the value, but may be able to select from a few pre-stored ID’s.** | ||
+ | \\ | ||
+ | \\ | ||
+ | {{ : | ||
+ | \\ | ||
+ | **In the above, the top key set is valid (1) and will provide the correct CSW. | ||
+ | The same is true for keyset 2. However, in the last example, the wrong ESW has been used for ID2, and so the correct CSW will not be recovered inside the receiver. This example illustrates what would happen if there were 2 receivers with different ID’s, and the recipient of ESW1 decided to pass it to another customer having a receiver with a different ID. The combination of ESW 1 and ID 2 would generate an incorrect CSW and the receiver would not be able to decrypt. ** | ||
+ | \\ | ||
+ | \\ | ||
+ | The same concept is used in both the encoder and the decoder and the algorithm used to relate the ESW, ID and the CSW is the same in every BISS-E compliant device. | ||
+ | \\ | ||
+ | \\ | ||
+ | {{ : | ||
+ | \\ | ||
+ | **The encoder and decoder both normally need an ID and ESW to be entered. The only difference is that the ID in the decoder is normally pre-set and cannot be read or changed. This stops key-sharing between customers since an ESW will only work in a receiver with a correct ID, and if all the ID’s are unique, then an ESW will only work in the one, intended receiver and no other!** | ||
+ | \\ | ||
+ | \\ | ||
+ | There are a number of ways in which this concept can be implemented and used in practice. The BISS standard lists two standardized ways known as “user mode” (which is mandatory) and “Buried_ID” (which is an option to EBU-TECH 3292 and is not implemented by TANDBERG for security reasons because it does not prevent the ID within a receiver from being read back by the user). In addition, there is a proprietary “TTV” method which is implemented on all TANDBERG receivers. | ||
+ | \\ | ||
+ | \\ | ||
+ | <color red>ser mode</ | ||
+ | \\ | ||
+ | \\ | ||
+ | TANDBERG receivers need to be put in BISS E “user mode” to allow entry of the ESW and the ID. Importantly, | ||
+ | \\ | ||
+ | \\ | ||
+ | <color red> | ||
+ | \\ | ||
+ | \\ | ||
+ | It is only possible for the manufacturer or specialist service departments to burn numbers into a receiver, and so this method provides an excellent way of obtaining a secure ID that is unique and that the user cannot change or read back from the device. This mode is also widely inter-operable between receivers and is used by large organizations (such as EBU). | ||
+ | \\ | ||
+ | \\ | ||
+ | <color red>TTV Mode</ | ||
+ | \\ | ||
+ | \\ | ||
+ | This also means that a unique ESW will be required for each receiver. The ESW will only work in the receiver possessing the correct serial number (and hence ID). Only this combination will result in the correct CSW being generated when this combination is passed through the BISS E algorithm. Using this method is proprietary to TANDBERG receivers, and is selected by placing the receiver in “BISS-E TTV” mode. | ||
+ | \\ | ||
+ | \\ | ||
+ | It completely prevents the possibility of valid keys being passed to others in an unauthorized way. Additionally, | ||
+ | \\ | ||
+ | \\ | ||
+ | This is because knowledge of the BISS algorithm alone is not enough to recover the ID that our proprietary technique creates; To achieve this you must have knowledge of how the serial number is used to create the ID which is kept internal to TANDBERG Television. The TANDBERG BISS E software tool is used to create the keys in the normal way and is described in detail later in this section. The tool is able to detect automatically that a TTV serial number has been entered as the receiver ID from the number length, and will then apply the proprietary process that converts it into a standard-length ID. | ||
+ | \\ | ||
+ | \\ | ||
+ | |||
+ | ---- | ||
+ | ==== Using BISS E ==== | ||
+ | \\ | ||
+ | Once the theory is understood, using BISS E is easy. To start, it will be necessary to configure the encoder and then configure the receivers. Both steps require the use of the TANDBERG (or equivalent) BISS E key generating software. This software is embedded within the encoder, and can be down-loaded onto a PC via an Ethernet connection. To do this, proceed as follows; | ||
+ | \\ | ||
+ | \\ | ||
+ | - Establish an Ethernet connection between the PC and the encoder, as though preparing to access the web-browser in the normal way. | ||
+ | - When entering the IP address of the encoder into the web browser, follow with “/ | ||
+ | - Go to “save / load” tab and “download BISS key generator”. Run the installation wizard and install the software onto your computer. You should see the following user interface when the software is run. | ||
+ | \\ | ||
+ | {{ : | ||
+ | \\ | ||
+ | Using the software is extremely easy. You will need it to configure the DSNG encoder and all of the receivers correctly. | ||
+ | \\ | ||
+ | \\ | ||
+ | ==== Configuring the DSNG encoder ==== | ||
+ | \\ | ||
+ | When in BISS E mode, the DSNG encoder will need to be configured by providing an ESW and ID which derives the CSW that you wish to use. Although the encoder has a menu option for the CSW to be entered directly, this is in fact disabled in BISS E mode, and any entries made into it will be ignored. The only active menus are the “encrypted session word” and the “injected user ID”. To generate these keys, you must create a database entry for the encoder and assign it a randomly generated ID. To do this, go to | ||
+ | \\ | ||
+ | \\ | ||
+ | UNIT, NEW, and then under the NAME heading, enter the description “DSNG Encoder”. Also enter a 14 digit number (please choose this at random) and then save the entry. You have now listed the DSNG encoder in the database and assigned it an ID. | ||
+ | The next step is to create the CSW that will be used. The CSW is also generated at random, and the software tool has a random number generator included to perform this task for you. Simply go to SESSION WORD NEW and accept the warning. The “current session word” tab will update with a new randomly generated number. | ||
+ | The final task is to use these two numbers (the CSW and the ID) to create an ESW. To do this, click the “authorize all” tab and then “Generate Key Data File”. This will create a text file which you can now view, containing the ESW | ||
+ | Enter the ESW and the ID into the DSNG encoder, and internally these numbers will generate the same CSW that is currently shown by the software. You should never tell anybody what the CSW is. With BISS E, there is no need to know what the clear session word is outside the task of generating the ESW and ID that will be used by customers. | ||
+ | \\ | ||
+ | \\ | ||
+ | Please note that this is the ONLY difference between BISS-E and BISS mode 1. Both standards are inter-operable in that the CSW is the same. With BISS mode 1, the CSW is simply known by all and entered directly, where as in BISS-E the CSW is “hidden” and only derived internally within the equipment using the combination of ID and ESW. Since this is the case, if you do know what the CSW is then please appreciate that there is no difference between using an encoder in BISS-E mode and entering a ESW and ID to generate the CSW, and putting the encoder in BISS mode 1 and entering the same CSW directly. Either will provide exactly the same outgoing transport stream. Likewise, if the ESW is not kept secret from receiver operators, they can use it to illegally decrypt your BISS E transmission by placing the receiver in BISS mode 1 and entering the CSW. The CSW can also be passed on to others who will also be able to decrypt your transmissions in the same way. | ||
+ | It is therefore imperative that the CSW is maintained a closely guarded secret. The person issuing the keys using the software tool is the only one who needs to know the CSW since in BISS-E mode, both the encoders and decoders can be set up using the safer ESW and ID. Customers should also not know the combination of ESW and ID unless it is unavoidable since the BISS E algorithm is freely published making it possible for a technically experienced user to use the ID and ESW to work out what the CSW is. | ||
+ | \\ | ||
+ | \\ | ||
+ | Configuring the receivers uses a very similar process. If you are using “user mode” (as described earlier) then the process is identical. In the same way, you need to create a database entry for the receiver, randomly assign it a 14 digit “injected user ID” and then <color red> | ||
+ | \\ | ||
+ | \\ | ||
+ | If you are using the receivers in TTV mode, then when creating the database entry for the receiver, you must enter the correct serial number for the receiver. This will be the electronic DALLAS_ID for the receiver and NOT the serial number taken from the label on the side of the unit! Finding the Dallas_ID depends upon the receiver type. Some display the Dallas_ID on the web-browser; | ||
+ | Using “fixed” key mode is identical to TTV mode in every way, except that the value of the fixed key must be known to the administrator and correctly entered into the database as a 14 digit (7 byte) number. | ||
+ | \\ | ||
+ | \\ | ||
+ | For security reasons, it is recommended that you periodically update the “clear session word”, but only when you are prepared to re-issue new keys for both the DSNG encoder and all of the receivers. | ||
+ | \\ | ||
+ | \\ | ||
+ | ==== Providing increased levels of security and functionality: | ||
+ | \\ | ||
+ | \\ | ||
+ | Although the security provided by the BISS open standard is sufficient to protect most contribution feeds of short duration, it is not ideal for providing longer term protection of high value content and cannot help with the management of larger contribution solutions. | ||
+ | TANDBERG Director has been engineered as the next step up from BISS in terms of both security and functionality and expands upon the capabilities of BISS by adding several layers of additional functionality. The key differences are as follows; | ||
+ | \\ | ||
+ | \\ | ||
+ | <color red> | ||
+ | Director improves upon this by ensuring that the encryption key is changed every few seconds. To achieve this, a new key is generated (typically every 20 seconds) and is automatically and securely transmitted to the receivers. Tight control over timing means that the key changes happen seamlessly, providing a dramatic improvement in system security. The automated process means that you do not have to get involved with any part of this process, saving a lot of effort. The keys are securely transmitted in encrypted form to the receives using an ECM mechanism. Furthermore, | ||
+ | \\ | ||
+ | \\ | ||
+ | <color red> | ||
+ | The security of the transmission is protected by the variable key system, making it highly secure. Unless the receiver can utilize the continuous stream of ECM’s which provide the key information in encrypted form, the original key cannot be recovered and so the link remains secure. | ||
+ | However, even if the ECM can be decrypted by a genuine Director receiver, there is a further stage of protection to go through before the content can be viewed. This mechanism involves the concept of “entitlements” and means that the receiver must be specifically authorized for each programme it can decode. This may sound complex, but the Director system makes it incredibly simple. The power this provides is equally incredible since you control what each receiver is authorized to view putting you in complete control. | ||
+ | Central to this mechanism is a scheduler where you can list all of the programs being aired for each channel. You can then assign an entitlement to any program you wish to protect. It’s that easy! The director system will automatically monitor the schedule and will securely carry the entitlement in the ECM message to the receiver. If it is a genuine Director receiver, then it will be able to decrypt the ECM and recover the encryption key, but it will also check the entitlement being carried in the ECM against a list of pre-stored entitlements that exist in a secure area of receiver memory. If there is a match, the key will be used to decrypt. If there is no match, then decryption will not take place and the user will be informed that viewing of the content is not authorized. Since there is a separate ECM for every service, this process will occur independently on every channel, allowing the content to be protected individually in a multi-channel environment. | ||
+ | \\ | ||
+ | \\ | ||
+ | ==== Entitling the receiver ==== | ||
+ | \\ | ||
+ | Since a receiver must have the correct entitlements to access the content a user has subscribed for, it is important to have a quick and easy means of controlling the entitlement lists within a receiver. Director achieves this by creating a secure message that is transmitted over-air called an EMM. The EMM is encrypted and addressed to applicable receivers automatically; | ||
+ | \\ | ||
+ | \\ | ||
+ | ==== Sending receiver commands ==== | ||
+ | \\ | ||
+ | Having developed such as simple yet powerful mechanism for sending messages to receivers over-air, we have now expanded this above the ability to simply send entitlements so that you can send hardware instructions to receivers as well. Using the same secure EMM mechanism, it is possible to instruct receivers to select another service, frequency change to another satellite, display an on screen message or lock out all user controls. This is just a small selection of the commands provided by Director, which importantly also includes the ability for receivers to start upgrading their software seamlessly over air. | ||
+ | As with other director features, you have complete control over the entire receiver network and can choose whether an individual, a group, or all receivers are affected by your commands. | ||
+ | \\ | ||
\\ | \\ | ||
biss.txt · Last modified: 2023/03/09 22:35 by 127.0.0.1