On the cable network security issue, the MSO's at the moment assign little importance to security measures which protect their content from piracy. So, as long as they don't take it out on the customer if/when piracy of future prized content becomes an issue (or are forced to address the issue by the true owners of the content), the security solution which is adequate for the moment is less complicated.
There is certainly some validity in the claim that piracy on a cable system is much more limited in potential scope than piracy of satellite or terrestrial services. However, the total value of the available premium content will be much higher for a cable system going forward, due to the breadth of services and the larger relative amount of content.
As for encrypting the data, the plan for DOCSIS's Baseline Privacy goes something like this:
The key management protocol uses RSA public-key algorithm (F4 public exponent and 768 bit public modulus) and Electronic Code Book (ECB) mode of DES for key exchange. The Cable Modem must possess an RSA Public-Private key pair.
The process of obtaining key material is described below in highly simplified form:
>>The Cable Modem (CM) submits an Authorization Request to the CMTS (the headend). This request contains (among other things) the CM's public key.
>>The CMTS replies with an Authorization Key (Auth_key) which is encrypted with the CM's public key (which can only be decrypted with the CM's private key, which only the CM has)
>>The CM decrypts the 768-bit encrypted Auth_key to extract the 64 bit raw Auth_key. This is used to generate 3 keys: A Key Encryption Key (KEK), an Upstream Message Authentication Key (UMAK), and a Downstream Message Authentication Key (DMAK).
[The KEK (a symmetric key) is used to encrypt Traffic Encryption Keys (TEK), which are used to encrypt the actual data traffic. The KEK-to-TEK encryption uses DES-ECB. The TEK-to-data encryption uses the Cipher Block Chaining mode of DES (DES-CBC).]
>>The CM then sends an authenticatable key request for a TEK to the CMTS. This request is authenticated by the CMTS using UMAK. CMTS knows what UMAK is because CMTS supplied the Auth_key it was generated from, and generates it on its end also.
>>The CMTS replies with: a TEK which is DES-ECB encrypted using KEK; a CBC initialization vector; a key sequence number (so the CM and CMTS can stay synched up as keys expire and new ones are obtained); a key lifetime for this key (so the CM knows when to get a new key), and an authentication string for this reply.
The CM then decrypts the TEK, and uses the initialization vector along with the TEK to encrypt traffic.
The domain of possible visibility of any given DES-encrypted stream is limited to a single MAC domain (or within a node if you will), so however-many households are served by a given MSO's ‘node breakdown' [about 2000 max]. So the only data that is encrypted is within the node. Beyond the node it is plain text. Note that the plain text may have been encrypted underneath this all if the CM was in a secure transaction mode in their internet connection (e.g. SSL); this is preserved.
----------
As for CDMA in-general and inherent security, not true in the purist sense. First, the complexity argument: complexity is a paper-thin method of security. One can make all sorts of arguments about the layers and layers of complexity, but those arguments are fairly week for standards-based products, especially in this day of million-gate FPGA's. With dozens of companies and hundreds of engineers working on these products (which are many times prototyped in FPGA's) all it takes is one engineer (or anyone with access to the files) enticed by a little cash to cough up the design files and pirate decoders soon appear.
As for the spreading codes themselves adding a level of security...weak. Crypto keys they are not. The spreading codes impart a noise-like flavor to the data, but not in a cryptographically significant sense. The spreading code sets (e.g. Hadamard or Walsh function-based) can be easily regenerated by anyone (i.e. anyone can discover the entire small set of possible keys), and are a very constrained (i.e. small) orthogonal subset of all possible binary sequences of a given length, (for example the 768-code Hadamard code set, those 768 codes would keel-over in a brute force attack in an instant). In TERN's case, my bet is its a much smaller number than that anyway--like 128 (just a guess--they don't divulge enough, but there's only so many orthogonal functions to use).
Compare that to this bit of trivia: A brute-force search for a 128-bit key on a computer system capable of trying 1 billion keys per second, and using a network of 1 billion of these systems, it would take 10-to-the-13th-power YEARS to try every possible key. This is approximately 1000 times longer than the estimated age of the universe.[from Garfinkel and Spafford].
So if the length of the key were the only factor determining the security, we'd run with 128-bit and cryptography would be a solved problem. Of course, that isn't the case...it's all the other forms of attacks that make up the bulk of the compromised data cases.
Sorry for all the acronyms...my fingers were tired.
Hope I didn't bore you to sleep!
dh
|
