text:
To prevent piracy, audiovisual content is encrypted prior to transmission to consumers. A low-cost, high-security cryptographic rights module (such as a smartcard) enables devices such as players/displays to decode such content. Security-critical functions may be performed by the cryptographic module in a manner that allows security compromises to be addressed by upgrading or replacing cryptographic modules, thereby avoiding the need to replace or modify other (typically much higher-cost) components. The security module contains cryptographic keys, which it uses to process rights enablement messages (REMs) and key derivation messages (KDMs). From a REM and KDM, the security module derives key data corresponding to content, uses public key and/or symmetric cryptography to re-encrypt the derived key data for another device, and provides the re-encrypted key data to the decoding device. The decoding device then uses cryptographic values derived from the re-encrypted key data to decrypt the content.
1. A method for using a removable cryptographic module to enable a second device to obtain secure access to encrypted compressed digital video content, comprising:
(a) receiving a rights enablement datum and a key derivation datum into said removable cryptographic module, where
(i) said rights enablement datum includes an encrypted representation of a key enabling decryption of said key derivation datum, and
(ii) said key derivation datum includes an encrypted representation of a key enabling said second device to decrypt said encrypted content;
(b) said cryptographic module transforming said rights enablement datum, using a key stored in said cryptographic module, to determine said key enabling decryption of said key derivation datum;
(c) said cryptographic module transforming said key derivation datum, using said key enabling decryption of said key derivation datum, to determine an initial content decryption key;
(d) said cryptographic module re-encrypting said initial content decryption key to produce a re-encrypted content decryption key datum, where:
(i) said re-encrypted key datum enables said second device to decrypt said encrypted compressed digital video content, and
(ii) said re-encrypting is secured by a public key corresponding to said second device; and
(e) transmitting said re-encrypted content decryption key datum to said second device.
2. The method of
3. The method of
(i) said second device transforming said re-encrypted content decryption key datum to determine a key for decrypting said content; and
(ii) said second device decrypting said content.
4. The method of
5. The method of
(i) decrypting said re-encrypted content decryption key to recover said initial content decryption key;
(ii) computing an exclusive OR of (A) said initial content decryption key and (B) an additional secret parameter; and
(iii) using a result of said exclusive OR operation as a key to decrypt said content.
6. The method of
7. The method of
8. The method of
9. The method of
10. The method of
11. A removable cryptographic device for enabling at least a second device to obtain secure access to encrypted compressed digital video content, comprising:
(a) a nonvolatile memory;
(b) a key stored in said nonvolatile memory;
(c) cryptographic logic configured to use said stored key to transform a rights enablement datum to determine a second key, where said second key enables decryption of a key derivation datum;
(d) cryptographic logic configured to use said second key to transform a key derivation datum to determine an initial content decryption key;
(e) cryptographic logic configured to re-encrypt said initial content decryption key in a manner secured using a public key corresponding to said second device; and
(f) an interface for communicating with said second device, configured to transmit said re-encrypted initial content decryption key to said second device.
12. The device of
13. The device of
(i) an interface for receiving said encrypted compressed video content;
(ii) a smart card interface for communicating with said cryptographic device, configured to receive said re-encrypted initial content decryption key;
(iii) high-speed decryption logic configured to decrypt said content using a key derived from said re-encrypted initial content decryption key; and
(iv) video decompression logic configured to decompress said decrypted content.
14. The device of
15. A removable cryptographic module enabling an associated device to obtain secure access to encrypted compressed digital video content, comprising:
(a) means for receiving a rights enablement datum and a key derivation datum into said removable cryptographic module;
(b) means for transforming said rights enablement datum, using a key stored in said cryptographic module, to determine a key enabling decryption of said key derivation datum;
(c) means for transforming said key derivation datum, using said key enabling decryption of said key derivation datum, to determine an initial content decryption key;
(d) means for re-encrypting said initial content decryption key to produce a re-encrypted content decryption key datum, where:
(i) said re-encrypted key datum enables said associated device to decrypt said encrypted compressed digital video content, and
(ii) said re-encrypting is secured by a public key corresponding to said associated device; and
(e) means for transmitting said re-encrypted content decryption key datum to said associated device.
16. The removable cryptographic module of
17. The removable cryptographic module of
(i) means, within said associated device, for transforming said re-encrypted content decryption key datum to determine a key for decrypting said content; and
(ii) means, within said associated device, for decrypting said content.
18. The removable cryptographic module of
19. A removable cryptographic device for enabling at least one associated device to obtain secure access to encrypted compressed digital video content, comprising:
(a) nonvolatile means for storing a key;
(b) means for using said stored key to transform a rights enablement datum to determine a second key, where said second key enables decryption of a key derivation datum;
(c) means for using said second key to transform a key derivation datum to determine an initial content decryption key;
(e) means for re-encrypting said initial content decryption key in a manner secured using a public key corresponding to said associated device; and
(f) means for transmitting said re-encrypted initial content decryption key to said associated device.
20. The device of
This application is a continuation of U.S. application Ser. No. 09/948,473, filed Sep. 6, 2001 and to issue as U.S. Pat. No. 6,640,305, which is a continuation of U.S. application Ser. No. 09/389,268, filed Sep. 2, 1999, now U.S. Pat. No. 6,289,455, both of which are hereby incorporated by reference in their entirety.
This patent relates to systems for distributing digital content, and more specifically to methods and apparatuses for improving the security of systems for distributing digital content.
Systems that protect valuable content require effective security. For content distributed in physical form, such as film being transported to movie theaters, physical security measures can be sufficient. Unfortunately, traditional physical security techniques are slow, expensive, cumbersome, and cannot be used with non-physical content distribution models. As a result, content providers rely on cryptographic hardware to ensure that only authorized users can access their data.
To prevent misuse of decryption keys, cryptographic hardware used to manage content decryption keys must be effectively tamper-resistant. Building effective tamper resistant hardware has proven extremely difficult, especially for systems that are the subject of determined attacks, because they are large or protect high-value content. As a result, many systems (including most satellite television systems) use replaceable security devices, such as smartcards, so that security can be re-established after an attack without replacing the entire playback system. Nevertheless, smartcards used for prepaid telephone, pay-TV, and transit applications are broken regularly. For example, prepaid telephone cards used in Germany were attacked in 1998 with estimated losses of US$38 million ("Pirates Cash in on Weak Chips," Wired News, May 22, 1998). Similarly, access cards and systems for cable and prepaid satellite television services are regularly "hacked," necessitating repeated costly card replacements.
Smartcards must effectively resist a variety of attacks against cryptographic algorithms, protocols, software, and chip hardware. Unfortunately, designing a smartcard that implements sophisticated protocols yet contains no security flaws has proven to be a very difficult task, since unexpected problems or errors in any portion of the design can render the entire card insecure. Cost considerations also favor attackers, since smartcards typically cost between $1 and $15, yet may be trusted to protect services or information worth thousands of dollars.
A smartcard system will only be attacked seriously if it is in the attacker's interest to break it. With smartcard designs of the background art, once attackers develop a means to compromise one card, the incremental cost to break a large number of cards is usually very small. As a result, smartcard security efforts typically focus on preventing the initial attack by making the card more difficult to break. For example, vendors try to increase the cost of reverse-engineering the device or imaging the card's ROM. Such techniques are helpful because they increase the cost required to break the system the first time, but for very large systems they are ineffective because attackers will devote enough effort to attacks that they will eventually succeed.
Prepayment and Post-Payment
In many systems of the background art, digital content is distributed in encrypted form. Access to the keys or algorithms required to decrypt the content is regulated by a rights management system that enforces the content owner's access policies. These access policies vary greatly in complexity. For example, the simplest schemes simply involve providing a decryption key upon payment, while the approaches described in U.S. Pat. No. 5,915,019 to Ginter et al. provide for rather sophisticated and flexible distribution mechanisms.
The two most common payment methods present in such schemes are prepayment and post-payment. Because these approaches have different security requirements, their architectures and typical requirements will be described separately.
In prepayment schemes, the user obtains prior authorization from the content provider. In typical prepayment systems, the user provides a payment (or a commitment to pay) then receives a content decryption key that allows access to the purchased content.
Prepayment systems must effectively be able to resist a variety of attacks. One class of attacks involves directly breaking the encryption (or any other protection mechanisms used to prevent unauthorized use of the content). Another attack involves capturing and redistributing the digital content after it has been decrypted. Other attacks involve unauthorized redistribution of the content decryption keys. Still other attacks involve capturing the content in analog form (e.g., as it is presented to the user).
Some of these attacks can be prevented effectively and others do not present a serious financial threat to content distributors. Strong encryption algorithms (such as triple DES) can reliably thwart attackers who do not have the correct decryption keys. Attacks against the decrypted content are not very serious if the content's value decreases rapidly with time or if the re-recording process significantly degrades the quality of the content. Watermarking techniques can also prevent, detect or trace some content recording attacks. Attacks that involve copying decryption keys are serious and have proven challenging to prevent. Because it is usually impossible or too expensive to transmit a different ciphertext to each potential user, attackers can purchase a decryption key once, then redistribute it to unauthorized parties.
Systems known in the background art distribute content decryption keys in encrypted form to a tamper-resistant cryptographic unit connected to (or part of) the user's playback device. Because decryption keys with long-term value are never exposed in unencrypted form, many attacks can be prevented—if the tamper-resistant module is unbreakable.
Because smartcards and other tamper-resistant cryptographic hardware commonly used to implement the cryptographic unit often have limited performance and bandwidth, the cryptographic unit is often used to generate short-lived subkeys from the main content decryption key. These subkeys are then transmitted to a less secure portion of the system, such as the main playback device, and used to decrypt the content itself.
The security of the system thus depends on the security of the cryptographic unit. If the cryptographic unit is compromised, attackers can determine the decryption keys and algorithms and use these to access content without authorization (e.g. by emulating an authorized cryptographic unit and/or the entire playback device).
In post-payment schemes, the user can decide to access some content without notifying the content provider or obtaining permission in advance. Instead, the content provider later audits the user's usage and determines the appropriate fees to charge. In some systems of the background art, post-payment is referred to as pay-per-view.
In addition to being susceptible to the attacks described above against prepayment systems, post-payment schemes are vulnerable to a variety of additional attacks. For example, the user's purchase audit records must be stored until the content provider retrieves them. Modification or destruction of these records can make it impossible for the content provider to determine the correct amount to charge. As a result, secure storage is required in the cryptographic unit for the audit data.
Although cryptographic techniques can secure the audit data from tampering (provided that the cryptographic unit has not been compromised), users generally do have the ability to prevent the audit process altogether. For example, in many consumer systems, two-way communication requires a telephone call, which users can prevent by simply disconnecting the telephone line. Users can often even destroy the cryptographic unit to conceal their purchases. As a result, measures are generally required to make users allow audits. For example, it is possible to penalize users by terminating service or preventing access to additional post-payment (pay-per-use) content if successful audits are not performed in a timely manner. Back-end systems can also charge users with penalties or other fees for audit noncompliance.
Post-payment systems involve more risk because purchases occur without live interaction with the content provider. As a result, each cryptographic unit is typically preprogrammed with the cryptographic keys for viewing all content the user might possibly purchase. As a result, compromise of a single cryptographic module can potentially compromise all post-payment content in a system.
Many systems combine prepayment and post-payment approaches. Prepayment is generally used to regulate access to content sold on a subscription basis. For example, access to electronic news services, music channels, subscription television channels, etc. are commonly sold on a prepayment basis. Premium content is often provided on a post-payment (pay-per-use) basis, where users can use content at any time but their cryptographic modules periodically provide the content provider with a list of the premium content that has been used. Post-payment of this type is used in the "Divx" video playback system as well as most cable and satellite television "pay-per-view" schemes. Prepayment protocols can be used for extremely high value pay-per-view content if penalties are insufficient to ensure successful auditing or if the risks are great enough to offset the cost and effort to initiate two-way communication with the content provider before access is authorized.
The Cryptographic Rights Unit (CRU)
A variety of designs and architectures have been proposed and used for cryptographic units that manage and protect the secret keys and algorithms used in content distribution systems. If legitimate users can be trusted to protect their keys, software-only approaches can be acceptable and have the advantage of avoiding the cost and expense of building and distributing specialized hardware. In many cases, however, tamper-resistant modules are required.
No architecture can provide perfect security. For example, an exact replica of an authorized satellite television receiver (including the receiver's cryptographic rights unit) will be able to view the same signals as the original. As a result, the security depends on preventing attackers from building working copies or emulators of authorized playback devices.
Commercially-deployed approaches usually use tamper-resistant hardware modules to enforce the content provider's access policies.
The ROM and/or EEPROM generally include software, which is executed by microprocessor 140. The software includes instructions that implement and/or manage protocols and cryptographic keys involved in decrypting content. Because cost, memory, and I/O bandwidth limits make it difficult to decrypt a large amount of data in the tamper-resistant module, the tamper-resistant module can supply content decryption keys for individual blocks or streams of content to the playback system, which performs the bulk data decryption. A cryptographic processor 150 can optionally assist with the cryptographic computations by reducing the amount of time or program code required for the computation or by implementing obfuscated algorithms that are difficult to reverse engineer.
To support both prepayment and post-payment, at least four basic operations are supported over I/O interface 145: adding new prepaid rights keys or privileges, recording purchases (for post-payment), deriving content decryption keys (for either prepayment or post-payment), and post-payment auditing.
The device of
Once the software is known, attackers can reverse engineer the code, yielding all cryptographic algorithms and keys contained in the extracted regions. Again, some techniques, such as the use of obfuscated or nonstandard software, can complicate this process somewhat.
If cryptographic processor 150 is not present, the attacker can then produce an emulator of the target device. Once an emulator has been developed, it is often difficult for the provider of the system to re-establish security without replacing all CRUs. Even if legitimate devices are configured to allow updates to the portions of their software or keys in EEPROM, the emulator will simply accept the same updates and continue operating unless the content provider manages to identify the compromised keys and stop providing service to the corresponding accounts.
If the emulator is imperfect and legitimate devices are configured to allow software updates, it may be possible to modify legitimate devices in a way that the emulator will not process correctly. Unfortunately, all the attacker has to do is correct the emulator. For example, pirates have produced CRU emulators that operate a personal computer and updated their emulator software to fix any errors in the emulator's operation.
Code update capabilities are a double-edged sword—although they can thwart some attacks, attackers may be able to subvert them to inject malicious code into legitimate devices. Although code updates can be protected with digital signatures and/or MACs (Message Authentication Codes), attacks against the hardware, software, and/or cryptography pose a significant risk. It may also be possible for attackers to insert code in other ways, for example by exploiting pointer errors to redirect memory updates to code regions.
For example, if the attacker is able to trick microprocessor 140 into executing malicious (i.e., attacker-written) code, then the attacker can use the first code to load more malicious code into EEPROM 125 or RAM 120. This malicious code can then further modify the device, for example by adding unauthorized functions that bypass non-cryptographic protections, delete post-payment audit records, add/modify/output cryptographic keys such as rights keys, etc. Although some techniques (such as hashing EEPROM contents as part of key derivation processes) have been attempted to detect some such attacks, these techniques tend not to be very effective and have been evaded by clever attackers. Although it would be possible to make microprocessor 140 execute only code from ROM 115, the system designers would then be unable to patch problems or transmit code updates to address bugs.
It is extremely difficult or impossible to reliably prevent all major attacks using architectures of the background art. Once attackers reverse engineer the software executed by microprocessor 140, they can identify and exploit software flaws or other implementation weaknesses. If these weaknesses in turn allow unauthorized modification of the device's software, the content provider's own cryptographic rights units (CRUs) and/or playback hardware can even be used to attack the system. The book European Scrambling Systems 5 by John McCormac (Baylin Publications, 1996) contains more information about how some existing systems have been designed and attacked and why architectures of the background art have proven ineffective.
Using architectures of the background art, any weakness in the cryptographic unit thus tends to cause a serious compromise of the entire device. Building a device that resists all known invasive and non-invasive hardware attacks, software attacks, protocol attacks, cryptographic attacks, fault induction attacks, etc. is extremely difficult—and new attacks may be discovered after a device is deployed. As a result, many content providers suffer from high piracy rates and the expense of replacing cryptographic units when they are broken.
The technologies disclosed herein can improve the security of systems used to distribute and protect digital content. In one embodiment, a tamper-resistant device for regulating access to encoded digital content includes an external interface, a microprocessor for controlling the external interface, a memory, a cryptographic unit connected between the microprocessor and memory configured to protect the memory from the microprocessor by cryptographically transforming data communicated between the microprocessor and the memory, and a device key accessible by the cryptographic unit and inaccessible by the microprocessor. The device is configured such that the cryptographic unit uses the contents of the memory to transform at least one data value received from the microprocessor, where the result of the transformation is required to decode the digital content.
Although it is impossible to design a content distribution system that is immune to all possible piracy attacks, it is desirable to minimize the probability that attackers will profit from attacks. A system does not need to be immune to all attacks; attackers are generally rational and driven by a profit motive, so illogical attacks will not proliferate widely. For example, if the attacker's cost and risk exceed the cost of purchasing the content legitimately, piracy is not a serious threat.
Attackers have both advantages and disadvantages as compared to legitimate service providers. Because their acts are often illegal, they incur higher risks. Their distribution costs and customer acquisition costs tend to be higher, since they generally cannot use traditional (legitimate) channels. The quality and reliability of pirate services also tends to be inferior. On the other hand, attackers have several major advantages. Most important, they obtain their content for free (i.e., by pirating it). In many cases they also co-opt part or all of a content provider's distribution channel (e.g., sales of encrypted optical discs, satellite broadcasts, Internet services, etc.), playback mechanisms (cable TV set-top boxes, DVD players, etc.), and other infrastructure. Finally, pirates' customers may be able to avoid cumbersome procedures imposed by the legitimate content provider for security, billing, etc.
Although attacker business models vary, the technologies disclosed herein are based on the premise that content providers can effectively eliminate piracy by making it unprofitable. It is thus desirable to increase the costs and risks incurred by attackers who steal content.
Content providers will only invest in anti-piracy measures that make business sense. When estimating the cost of content piracy to content providers, several factors should be considered. Direct revenue losses occur when potential subscribers instead buy pirated content. In cases where content providers subsidize the costs of media, distribution, playback hardware, technical support, etc., illegitimate users can also increase expenses. If piracy is widespread, content providers may be unable to obtain premium content or will have to pay more to content owners to compensate them for lost royalties. Costs for enforcement and prosecution can also be significant. Paying users may even feel discouraged if they see others getting for free what they are paying for, reducing the perceived value of a service. It is thus desirable to achieve improved security without unduly increasing costs or hassles for content providers or legitimate users.
Traditional content protection schemes generally seek to maximize the cost of any unauthorized access, but do little to increase the cost of decoding messages once the decryption scheme has been broken. In addition to preventing attacks, it is also desirable to seeks to minimize the proliferation of unauthorized decoding devices if an attack does occur, since the damage due to piracy increases with the number of unauthorized users. For example, one might seek to increase or even maximize the cost of producing multiple unauthorized pirate devices even after one device has been compromised. This is attained in part by forcing attackers to repeat complex and expensive physically-invasive attacks for each pirate device that is produced.
The following description is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the general techniques disclosed herein.
Exemplary Meanings
The following are provided as exemplary meanings of some commonly used terms in this patent. However, unless expressly indicated, these exemplary meanings should not be understood to supersede other possible meanings (including their customary ordinary meanings) known to those skilled in the art. In addition, although capitalization has been used as an aid to readability, such capitalization should not be construed as limiting the meaning of such terms to the various exemplary disclosures contained in this patent. Rather, the terms should be given their entire range of possible meanings not inconsistent with the disclosure of this patent.
Asymmetric Function: An easy-to-compute function for which a complementary operation (such as its inverse) is computationally hard without a private key, but easy to compute with the private key. The RSA cryptosystem is thought to be asymmetric, since inverting the public key operation (i.e., performing the private key operation) is only easy with if the private key is known.
Content Decryption Key (CDK): A key required to decrypt some encrypted digital content.
Content Provider: An entity that manages the cryptographic portions of a content distribution system. The content provider is also generally responsible for distributing or broadcasting the content, billing, customer service, etc. The content provider tasks can be divided among many companies.
CryptoFirewall: A specialized circuit placed between the interface control processor (ICP) and a protected memory which is designed to control access to (and use of) the protected memory even if the ICP is compromised. In addition, the CryptoFirewall uses the protected memory to derive content decryption keys.
Cryptographic Rights Unit (CRU): A tamper-resistant hardware device designed to perform cryptographic operations that allow authorized users to gain access to digital content.
Device key: A cryptographic key or other security-related parameter that is preferably specific to a particular device, but may also be shared by a small number of similar devices.
Digital content: A digital representation of human-interpretable material, such as pictures, audio tracks, video segments, text (such as books, magazines, news feeds, stock quotes, etc.), etc. Digital content is often encrypted and/or compressed and may include error correcting codes and other auxiliary data.
Interface Control Processor (ICP): A microprocessor responsible for processing communications between the cryptographic rights unit and a playback device. The ICP is also generally responsible for communicating with the CryptoFirewall.
ISO 7816 Smartcard: A device complying with at least the physical dimensions and contact configurations specified in ISO standard 7816-1 and 7816-2. Smartcards are commonly used to implement CRUs, as they provide a reasonable degree of tamper resistance at relatively low cost.
Key Derivation Message (KDM): A message generated by a content provider to allow a CRU to derive a decryption key corresponding to some digital content. KDMs are usually transmitted with the corresponding content.
Playback Device: A device that receives digital content via an untrusted mechanism (such as radio, optical disc, digital audio tape, cable, satellite broadcast, Internet connection, etc.) and, using a CRU, decodes the content. The bulk data decryption operation can be performed by the CRU itself or by the playback device using a key generated by the CRU.
Pseudoasymmetric Function: A function (transformation) designed such that attackers cannot easily perform the inverse transformation even with direct access to the forward transformation. For example, an attacker with access to a pseudoasymmetric encryption function does not necessarily have the ability to decrypt meaningful messages. Unlike traditional asymmetric cryptographic functions, however, the noninvertability of a pseudoasymmetric function relies on the difficulty of completely reverse engineering the "public" function instead of the difficulty of performing a mathematically hard operation such as factoring. A block cipher implementation with a physically-protected key and/or algorithm that only supports encryption is an example of a pseudoasymmetric function, since unrestricted access to the encryption operation alone does not allow decryption of messages.
Rights Enablement Message (REM): A message generated by a content provider that gives a CRU the ability to access new content. The REM itself is usually transmitted via the same untrusted mechanism as the content itself, although in some cases REMs may be exchanged through other channels (such as separate telephone or Internet connections).
Rights Key: A value (such as a cryptographic key) that allows a CRU to generate or decode the decryption keys for some content. Rights keys are generally required to decrypt KDMs and obtain content decryption keys.
Tamper-Resistant Device: A hardware device whose operation is relatively difficult to monitor and/or modify. Examples of tamper-resistant devices include without limitation PCMCIA cards filled with epoxy, circuits covered with tamper-resistant coatings, circuits wrapped in tamper-detecting wire, integrated circuits (which are tamper resistant due to their small feature size), and circuits in enclosures that detect opening.
System Architecture
The encrypted content data is then distributed (process 205) by the Content Provider in a manner such that it can be received by authorized (e.g., paying) users as well as potential attackers. A variety of distribution methods may be employed, including without limitation distribution of physical media (such as optical discs), radio or satellite transmission, wired networks (such as telephone, ADSL, cable television, etc.), and distribution over computer networks (such as publication on a web site, multicast, etc.)
Playback device 210 receives the distributed data for some content to be decoded. In the exemplary embodiment shown in
In the exemplary embodiment, control messages 220 include Key Derivation Messages (KDMs) and Rights Enablement Messages (REMs). These messages are transferred by playback device 210 to Cryptographic Rights Unit (CRU) 225. Playback device 210 can optionally perform processing or filtering before sending messages to CRU 225.
CRU 225 includes an interface control processor (ICP) 235, which is responsible for communication with playback device 210 via I/O interface 230. In addition, CRU 225 includes several types of memory connected to interface control processor 235 via bus 240. In particular, fixed data and code are stored in ROM 245, temporary data (and possibly code) are stored in RAM 250, and additional code and/or data are stored in EEPROM 255 which can be modified by processor 235. Also attached to bus 240 is CryptoFirewall 260, a specialized cryptographic processing unit whose operation is explained in detail below. CryptoFirewall 260 regulates and cryptographically modifies data written to or read from protected memory 265.
To decode some content, playback device 210 transmits to interface 230 a KDM corresponding to some content 215 to be decoded. Interface control processor 235 receives the KDM and, as described below, uses CryptoFirewall 260 to derive one or more content decryption keys 267, which are transferred to bulk decoder 270 via playback device 210. With the correct keys 267, bulk decoder 270 can correctly decrypt content 215. The decrypted content 275 is then sent to an output device 280, which presents the content to user 290 by converting it into a human-readable form (process 285). For example, if the system is configured to play audio content, decrypted content 275 could be an analog or digital representation of a sound, and output device 280 could be an amplifier and speakers. Similarly, if the system is configured to play movies on a television set, bulk decoder 270 could perform decryption and MPEG decompression, outputting decrypted content 275 as an NTSC-compatible video signal so that output device 280 can be an ordinary television set.
A communication channel from CRU 225 to content provider 200 is also provided for auditing post-payment purchases. This channel can also be used for transmitting REMs, other usage data, code updates, etc. Communication from the CRU to the content provider can be direct 296 or (more commonly) indirect 295, e.g. passing through playback device 210 which can (for example) establish a connection with content provider 200 as needed. Any communication method (including without limitation modem, radio, satellite, cable, etc.) can be employed.
CryptoFirewall Operation
The CryptoFirewall cryptographically regulates access to a protected memory. Unlike conventional memory encryption devices (such as the encrypted memory device of U.S. Pat. No. 5,442,704 to Holtey), the CryptoFirewall does not act transparently or allow arbitrary read or write operations to be performed by the microprocessor. In particular, the CryptoFirewall does not need to provide the microprocessor with the ability to store data values in the protected memory and read the same values out later. Conventional secure memory schemes are typically used to allow a trusted computational device to access memory that is less secure. In contrast, the CryptoFirewall is designed with the opposite assumption, that the interface control processor is untrusted but attackers do not have direct read/write access to the memory behind the CryptoFirewall. In other words, the CryptoFirewall can allow the cryptographic rights unit to remain secure even if the CRU's main microprocessor is compromised, provided that attackers do not completely breach the firewall and gain unrestricted access to the protected memory.
The CryptoFirewall implements a set of basic operations involved in adding and using content access rights. In the exemplary embodiment described with respect to
The exemplary CryptoFirewall uses several keys, which are stored in protected memory 265 and loaded during personalization (described below). In one embodiment, the protected memory is an EEPROM containing a device key (CHIP_KEY), at least one group key shared by (for example) 32 cards (BATCH_KEY), a post-payment authorization key (POSTAUTH_KEY), and several rights keys. Portions of the protected memory containing device keys and group keys can be written during personalization, then locked (write protected) to prevent future modification. Alternatively, these values can be stored in ROM, within or accessible by the CryptoFirewall.
Adding new rights by prepayment:
Adding new rights by post-payment: Rights added by post-payment are different from prepaid rights because no explicit communication or prior authorization is available from the content provider.
Accessing content: Before a user can access some content, the playback device must obtain the correct content decryption key (CDK) so that the content can be decrypted.
Auditing and Clearing Post-Payment Rights: A secure audit process is required to allow the content provider to charge users for post-payment purchases. To perform an audit, the content provider must be able to receive data from the cryptographic rights unit, for example through a modem or computer network connection with the playback device. The audit process can be controlled by the interface control processor, which in turn communicates with the CryptoFirewall.
Multiple Targeting: In some environments, it may not be feasible to broadcast different REMs to all users. For example, if REMs are distributed with content stored on optical discs, broadcast by radio, or sent via satellite, the data required for REMs is typically distributed to all users. As a result, the bandwidth and cost for distributing REMs increase as the system grows larger and can eventually become prohibitive. It is possible to reduce the amount of REM data by allowing multiple authorized CRUs to use each REM.
During personalization, keys including the CHIP_KEY and BATCH_KEY are added. If manufacturing processes allow, these keys can be stored in the CryptoFirewall during manufacture, for example by blowing on-chip fuses. They can also be stored in the protected memory, but care should be taken, however, to prevent attackers from being able to store key values from one CRU in another. Methods usable to prevent such attacks include preventing write access to the key regions after personalization (e.g., by blowing a write-protect fuse), cryptographically regulating access to these regions, and disabling either bit clearing or bit setting operations to prevent attackers from transforming one key into another. (Valid keys can be chosen with equal numbers of set and clear bits to ensure that key changes will require both setting and clearing bits.) It is even possible to allow modification of the keys, provided that changes performed using non-invasive attacks have a high probability of corrupting the key without producing useful results.
Pseudoasymmetric Function Generation
Pseudoasymmetric functions are included in preferred architectures as they can help limit the consequences if a single device is compromised. Cryptographic protocols alone (without hardware tamper resistance) cannot prevent many attacks against broadcast content distribution systems, since an unauthorized replica of an authorized playback system will be able to decode signals. As a result, the hardware implementation should be difficult to reverse engineer or clone.
In one embodiment, a pseudoasymmetric algorithm is produced using a software-implemented generator. The generator constructs a randomized algorithm using data from a random number source, such as a true random number generator, a pseudorandom number generator (such as a stream cipher), a pre-computed randomized input file, etc. The generator uses the random data to automatically design a hardware circuit that performs a cryptographic transformation. The purpose of the random source is to ensure that the circuit construction and the function it performs are unknown to attackers.
The outputs of NAND gates 820 are labeled W0 through W63. Each of these is connected to one or more of X0 through X127 (labeled 835), where the specific choice of connections is made by the PAFG. The remaining inputs to XOR gates 840 are connected to randomly-selected bits from C0 . . . C15, K0 . . . K127, and/or U1 . . . U127. The XOR gate outputs 850 (labeled Y0 through Y63) are connected by the PAFG to inputs randomly selected from Z0 through Z127 (labeled 855). The remaining inputs to the final set of NAND gates 860 are selected from among C0 . . . C15, K0 . . . K127, U1 . . . U127, W0 . . . W63, and Y0 . . . Y63. Finally, the outputs of NAND gates 860 and the original 128-bit shift register's left-hand bit 805 are XORed together by XOR gates 870, producing a single-bit result 880. The 128-bit shift register 800 is then shifted left one position (i.e., storing the contents of bit 1 into bit 0, bit 2 into bit 1, but 127 into bit 126, etc.) and the single result bit 880 is placed in bit position 127. To transform an input block, the operation shown in
Of course, the implementation illustrated in
In some CryptoFirewall embodiments it is advantageous to use multiple pseudoasymmetric functions to ensure that outputs from one operation cannot be used to attack other operations. To reduce the size of an implementation, it is possible to share many or all logic components between these functions. A single transformation circuit can provide multiple operations if a transformation selector is used. For example, a 3-bit function identifier placed in the most significant 8 bits of the counter in C0 . . . C15 shown in
The output of the PAFG can have any form, but is typically a circuit representation that can be included directly in an application-specific integrated circuit (ASIC). For example, standard languages (such as Verilog and VHDL) for designing integrated circuits may be used as the output format. Additional automated or manual modification of the output (such as adding basic structures around the function, optimizing the operation, etc.) can be performed if required.
In a preferred embodiment, the PAFG also outputs a circuit definition for the inverse function in addition to the "forward" function. A hardware implementation of the forward function is distributed to untrusted parties, for example in the CryptoFirewall, while the inverse is typically managed securely by the content provider(s) and used to prepare content, REMs, KDMs, etc. for distribution. Because the devices that contain the inverse function are operated by the content provider, they can be stored in physically-secure locations. As a result, tamper-resistance is not required, so the inverse may (for example) be implemented in software or in programmable integrated circuits (such as FPGAs).
It is possible for the PAFG to be configurable to produce output tailored to the implementation. For example, output can be tailored to accommodate different circuit description languages, circuit sizes, layouts, logic gate (or logic cell) types, and wiring limitations. For example, in one embodiment, the PAFG is configured to produce a circuit of variable size so that a system designer can select an output circuit whose size corresponds to the amount of space available on a chip's die.
One major advantage of the PAFG architecture is that it can produce circuits that are difficult to reverse engineer while still allowing open cryptographic evaluation. The PAFG itself does not need to contain any secrets because it constructs the output circuit using interconnects and other design parameters generated using a random source. As a result, the PAFG design and implementation can be analyzed—or even published for open review—to assess whether there is any significant chance that the PAFG will generate a cryptographically insecure function. The PAFG architecture thus allows for unrestricted use of outside review and does not require burdensome security precautions on the reviewers typically required when using obfuscated algorithms. The PAFG thus provides resistance to reverse engineering without relying on security by obscurity. (Of course, PAFG implementations that do not use good random sources can be constructed as well, but are not preferred.)
An Exemplary Simplified Architecture
The complexity of the CryptoFirewall described with regard to
The embodiment of
With a modest addition of complexity, the
Post-paid rights slots can be designated as empty if all bits are cleared (or set). In this case, the update processes used in (b) and (c) above require only writing (or clearing) bits in the protected memory. If the protected memory uses a technology such as EEPROM where bit clearing and bit setting operations are performed separately, the post-payment addition process can be implemented so that purchasing and clearing each use one type of bit operation.
To audit post-paid purchases, the content provider can (for example) use the standard key generation process and provide a random challenge for the data block at step 920. The output from step 950 is compared with expected values for post-paid purchase keys to identify the key in the protected memory. (Alternatively or in addition, purchase data can be obtained from the ICP or additional logic can be provided in the CryptoFirewall for audits.) Because the audit clearing process is secured using a chip-specific key, attacks that modify audit data will have limited effectiveness. In particular, audit records will only be cleared if the content provider has correct audit data. As a result, the number of purchases that can be performed without paying is limited by the number of post-payment audit record slots in the CryptoFirewall. For risk management, the content provider can initially ship CRUs with only a few empty slots, then gradually clear slots as customers establish their trustworthiness.
Another Exemplary Simplifled Architecture
This section outlines a simplified CryptoFirewall architecture that only provides security for pre-paid content purchases. This embodiment has the advantage of being able to use volatile memory instead of writeable nonvolatile memory behind the CryptoFirewall. Because volatile memory is often easier to implement (e.g., because only standard logic components are required), manufacturing and design costs can be reduced.
Embodiments invention that use only volatile memory require access to a unique parameter that cannot be replaced by attackers. This unique parameter is preferably embedded into the circuit, for example using ROM or blown fuses. Techniques for embedding unique parameters in chips are known in the background art. For example, U.S. Pat. No. 5,799,080 to Padmanabhan et al. describes techniques for embedding serial numbers and cryptographic keys in integrated circuits.
At step 1010, the CryptoFirewall verifies that the bit in the key mask corresponding to its BATCH_OFFSET is set. For example, if the CryptoFirewall's embedded BATCH_OFFSET is binary 101110 (46 decimal), the CryptoFirewall will verify that bit 46 of the key mask value is set and, if not, the processing terminates. In an alternate embodiment, the CryptoFirewall sets the bit corresponding to the BATCH_OFFSET if it is not already set. (Of course, alternate embodiments can use encodings other than binary "1" for valid, use other testing processes, decrypt or otherwise process the key mask before testing, corrupt the key mask if the BATCH_OFFSET bit is not set, use batch offsets that involve multiple bits in the key mask, use multiple key masks, etc.)
At step 1020, the CryptoFirewall copies the validated key mask value from the input register to the CryptoFirewall's protected memory. The CryptoFirewall can optionally perform some cryptographic processing of the value during this copying.
At step 1030, the ICP loads a 64-bit encrypted rights key into the CryptoFirewall's externally-accessible register. Under normal operation, this key corresponds to some content a user wishes to decode. Encrypted rights keys are normally obtained by the ICP from a REM that was transmitted by the content provider. Because rights keys may last a considerable period of time (e.g., 30 days for a month-long subscription to a cable TV channel), encrypted rights key values can be cached (with the corresponding key mask) in nonvolatile memory external to the CryptoFirewall.
At step 1040, the CryptoFirewall applies a pseudoasymmetric transformation to the encrypted rights key. The pseudoasymmetric transformation is keyed using the XOR of the protected memory contents (i.e., the verified key mask value) and the BATCH_KEY loaded during manufacture. The transformation result is stored in the protected memory, replacing the key mask.
At step 1050, the ICP stores an encrypted content decryption key in the CryptoFirewall's externally-accessible register. The encrypted content decryption key is typically obtained from a KDM distributed by the content provider with the content to be decoded.
At step 1060, the ICP applies a pseudoasymmetric transformation to the encrypted content decryption key. As in step 1040, the pseudoasymmetric transformation is keyed using the XOR of the protected memory contents (i.e., the decrypted rights key) and the BATCH_KEY loaded during manufacture. The transformation result is stored in the externally-accessible register, where it can be read by the ICP at step 1070 and used to decode the content.
The data input to pseudoasymmetric transformation 1130 is encrypted rights key 1125, which is transformed and the result is stored in protected memory 1135 (which is the same as protected memory 1110). Combination logic 1140 optionally combines BATCH_KEY 1145 (which is the same as BATCH_KEY 1120) with the protected memory contents and provides the result as a key to pseudoasymmetric transformation 1155. Combination logic 1140 is optional; for example, the output of pseudoasymmetric transformation 1130 can be used directly to key transformation 1155. Note that transformation 1155 does not need to be invertable. For example, a keyed hash function such as HMAC can be used instead of a pseudoasymmetric function.
Encrypted content decryption key 1150 is transformed by pseudoasymmetric transformation 1155, yielding content decryption key 1160. (In an alternate embodiment where the CryptoFirewall directly decrypts the content itself, the content itself or a portion of the content may be supplied instead of encrypted content decryption key 1150.) Note that further processing on the content decryption key 1160 can be performed (e.g., by the ICP, playback device, etc.) before the actual content decryption is performed.
To ensure that operations are performed in the correct order, the CryptoFirewall should keep track of the current state in the transaction processing. For example, the CryptoFirewall should not allow reading of any results until it has completed processing.
To distribute a rights key, the content provider first chooses the value of the rights key and identifies one or more CRUs in a batch that will be authorized receive the key. Next, the content provider constructs a key mask by setting the bits corresponding to the authorized CRUs' BATCH_OFFSET values. From the mask and the BATCH_KEY, the content provider can assemble the output of logic 1115. Using the inverse of pseudoasymmetric transformation 1130 (e.g., as prepared by the PAFG) with the output of logic 1115 as the key, the content provider can compute encrypted rights key 1125 for distribution.
If bandwidth for key distribution is not limited, the batch key capability included in
The architecture of
Many variant embodiments are possible. For example, other combination processes (such as encryption, pseudoasymmetric transformations, modular addition, etc.) can be substituted for XOR logic 1115 or logic 1140 in
Physical Implementations
The physical implementation of the CRU can have several forms. A preferred implementation involves combining the interface control processor (as well as its memory) with the CryptoFirewall and protected memory on a single chip, which is then placed in a smartcard or PCMCIA card (PC card). Because the CryptoFirewall security model does not assume that the interface control processor (ICP) is completely secure, the CryptoFirewall should be implemented in hardware separate from the ICP, for example as a separate circuit on the same integrated circuit.
The protected memory used by the CryptoFirewall can be separate from, or part of, nonvolatile and/or volatile memory accessible by the ICU. If the CryptoFirewall and ICP share memory regions, the CryptoFirewall is responsible for ensuring that the ICP cannot inappropriately access the protected memory without the required cryptographic transformations. In particular, the CryptoFirewall should intercept and process accesses to protected regions while allowing other accesses to pass through it.
The CryptoFirewall architecture can be combined with hardware and chip card security features known in the background art. For example, detectors can be included to reset the device if unusual operating conditions (such as high/low operating voltage, high/low temperature, high/low/irregular clock signals, radiation, etc.) are encountered. Tamper-resistant coatings, chip obfuscation techniques, conventional memory encryption techniques, error detection/correction logic, intrusion detectors, etc. can also be used. If potential attacks are detected, the CryptoFirewall can (for example) erase any internal registers, reset itself, reset the ICP, and optionally even erase the protected memory.
The CryptoFirewall may be implemented using dedicated hardware (discrete logic) or using a separate microprocessor. In one preferred embodiment, two microprocessors (each with its own RAM, ROM, and EEPROM) are integrated onto a single chip, which is then embedded in smartcard packaging. One microprocessor serves as the ICP and communicates with the second microprocessor which is the CryptoFirewall. Although a dual-microprocessor CRU is somewhat more expensive to manufacture than the single-microprocessor CRUs in use today, it has the important advantage that the inner microprocessor (CryptoFirewall) is shielded from many attacks by the outer microprocessor.
The clock signal used to drive the CryptoFirewall can be taken from (or derived from) an external clock interface, generated internally, or supplied by the ICP. If present, clocks derived internally by the EEPROM circuit for timing write operations can also be used. External clocks should be used with caution to ensure that disruptions in the clock signal will not cause computation errors that could be used to attack the circuit. Clock dividers and multipliers can also be used.
The CRU can be implemented in a wide variety of forms. For example, components 210, 270, 280, and 225 in
In one preferred embodiment, the entire CRU is implemented in a single smartcard. Alternatively, the CRU can be a PCMCIA card. The CRU can also be a part of the playback device and can be integrated with other portions of the playback system such as bulk decryption, content decompression, and/or output. For security reasons, the CryptoFirewall needs to be an independent circuit from the interface control processor, but can have any form (e.g., a hard-wired circuit, an independent microprocessor, etc.)
The CRU can be integrated into the playback device, providing the benefit of making it more difficult for attackers to capture or insert content decryption keys exchanged between the playback device and the CRU. As a result, some key redistribution attacks can be prevented. (For content whose value is not time-sensitive or for systems operating in jurisdictions where anti-piracy laws are unavailable or unenforced, such attacks are of particular concern. Key redistribution attacks may also become more dangerous as computer networks such as the Internet can provide attackers with new methods for redistributing keys.) Physical integration of the CRU with the playback device has the disadvantage of making it more difficult to replace the CRU if an attack does occur. Alternatively or in addition, the content provider can withhold key derivation messages until they are actually required by the playback device to minimize the amount of time available for attackers to redistribute keys. Playback devices can also halt if keys are not received in a timely fashion.
Preparing Content
Digital content is usually distributed in compressed form. Processes for creating, formatting, and compressing content of different types are well known in the background art. In most situations, content is encrypted after it is compressed, since encrypted material does not compress well. Occasionally, however, compression and encryption are combined or simple encryption is applied before compression.
The key(s) used to encrypt the content are carried in the content's KDMs, which are secured with rights keys distributed in REMs sent to authorized users. KDMs can specify combinations of rights keys required to access content. For example, if two rights keys should be required to access a particular block of content, the content provider can first generate an encrypted key block (e.g., corresponding to encrypted content decryption key 1150 in
In an alternative embodiment, the content provider can begin by selecting a content decryption key. This key may be (but is not required to be) random. The content provider then uses the inverse of the CryptoFirewall pseudoasymmetric function to encrypt the content decryption key with a first rights key. If a second rights key is also required to access the content, the content provider can then use a second rights key to encrypt the content decryption key. The content provider then packages the encrypted CDK into a KDM for distribution and encrypts the content.
Content providers can also broadcast "fixup" values in KDMs that can enable CRUs with any of several rights keys to decode the content. In such cases, the ICP typically locates the address of a valid rights key, uses the CryptoFirewall to process an encrypted rights key, and XORs (or otherwise combines) the CryptoFirewall result with the key fixup value to derive the actual content decryption key. For example, if any of three rights keys (K1, K2, and K3) should allow access to some content and the CryptoFirewall key derivation process is denoted F(Ki,X) where X is a data block and Ki is a BLOCK_KEY, the content provider can choose F(K1,X) as the content decryption key. The KDM can then include F(K1,X) XOR F(K2, X) to enable CRUs with only K2 to derive the content decryption key. Similarly, including F(K1,X) XOR F(K3, X) allows CRUs with K3 to decode the content. This "either/or" rights key selection operation can be combined with the "and" operation described above to allow the content provider to establish sophisticated rules as to which CRUs can decode content. Fixups can also be used to produce compatibility between CRUs of different types (e.g., during periods where CRUs are being replaced and two versions are supported). Because the key combination rules are secured cryptographically, the KDM parsing and key construction processes can be implemented in the ICP.
It is possible (and often advantageous) to change content decryption keys frequently, for example by requiring a new KDM and a new key for each one-second or one-minute block of content. If desired, blocks can be protected with different combinations of rights keys. To reduce the latency experienced by users when they begin to decode some content, the content provider can make key changes coincide with places where the decompression algorithm can resynchronize. For example, with MPEG-2 compressed video, key changes can be made to coincide with I pictures.
Comments and Considerations
Under the architecture outlined in
In order to compromise the system, the attacker must do one of two things: either duplicate the functionality of the CryptoFirewall's pseudoasymmetric transformation or gain the ability to use a CRU's CryptoFirewall for unauthorized purposes. The former attack is effectively prevented by making it difficult to reverse engineer the randomized transformation circuit. In addition, for large deployments, groups of CRUs can contain different pseudoasymmetric functions to reduce the consequences of a successful reverse engineering attack. Use of group-specific keys (such as BATCH_KEY values) to broadcast periodic rights keys (such as hourly or daily keys) can also reduce the consequences of many reverse engineering attacks.
If the CryptoFirewall is implemented properly, a physically-invasive attack should be required to gain unauthorized control over the protected memory. If the CRU is implemented as a single-chip device (such as a smartcard) with reasonable physical security measures, physically-invasive attacks pose relatively little risk of being performed on a large number of devices because, even after such an attack has been identified, attackers still have to perform the time-consuming and expensive process of decapping, modifying, and remounting each target chip. These techniques also require expensive equipment and have a fairly high chance of damaging the target chip. As a result, most systems will not experience significant amounts of piracy even if attackers discover a physically-invasive attack that breaches the CryptoFirewall.
The architecture does assume that some devices will be attacked invasively, and therefore minimizes the usefulness of the keys and other data that could be obtained. In particular, a physically invasive attack will potentially provide an attacker with the ability to read from and/or write to the protected memory of the compromised device. Embedded keys (such as BATCH_KEY or BATCH_OFFSET) could be read and/or modified. Simply reading the protected memory contents provides no particular value, since the keys stored in the memory are not useful without the algorithms implemented in the cryptographic unit. The ability to write to the memory can, however, enable some significant attacks, since it then becomes possible for the attacker to delete post-payment records, insert new authorization keys, or modify batch offsets. A properly-functioning CryptoFirewall is still required, however, to process these values into content decryption keys. As a result, the attacker's work modifying one chip can yield one fully-functional pirate device, but should not lead to a general attack that can be marketed on a wide scale.
This section presents several examples of modified embodiments, and other variants will be evident to one of ordinary skill in the art.
The technologies disclosed herein may be used in conjunction with other content protection mechanisms. Content can be watermarked to trace compromises, identify copyright owners, etc. Non-cryptographic security measures can be added in the CRU, playback device, etc. and can help by increasing the effort required for an attack. Tamper evidence (in addition to tamper resistance) in the CRU can help to discourage attacks and prosecute pirates.
In addition to providing a "positive" benefit of adding rights, REMs can also have negative effects such as disabling a CRU by deleting or corrupting a rights key. Such negative effects can be implemented by the ICP and/or by the CryptoFirewall. To prevent attackers from blocking all REMs, the content provider can combine KDMs and REMs or make them indistinguishable (e.g., by encrypting them).
Data blocks in KDMs (e.g., such as the data block received by the CryptoFirewall in
The process performed to derive the content decryption key can include multiple rights keys and/or transformations. For example, multiple iterations of the process shown in
A content provider can, for example, require that CRUs contain multiple rights keys to access some content. For example, a block of content might require a general rights key that is updated frequently (e.g., hourly), a stream-specific rights key, a post-payment purchase authorization key, a post-payment audit key (indicating that a successful audit was performed recently), a region key (to enforce sports programming blackouts or other geographic restrictions), and/or a premium service rights key.
The ICP can be involved in cryptographic computations. For sophisticated KDMs, the ICP can identify and extract the components usable by the CryptoFirewall, manage I/O with the playback device and CryptoFirewall, and combine results to produce valid content decryption keys. The ICP can also perform additional cryptographic processing on REMs and/or CDKs. Although the CryptoFirewall may be designed with the assumption that the ICP is not a trusted part of the system, it does not cause any harm to also include security in the ICP so that attackers will not succeed unless they compromise both. Some security-related operations (such as local blackouts of sporting events) are relatively unlikely to be the focus of concerted attacks and are difficult to implement in dedicated circuitry, and therefore can be performed by the ICP.
Not all data needs to be protected to the maximum possible level of security. Occasional deletions, for example, are usually sufficiently irritating to prevent attacks that do not decode all of the content. Because compression techniques can make even single bit errors disrupt playback, strong protection over just a few percent (or less) of the total content can be sufficient. As a result, adequate security can often be obtained despite challenging bandwidth or performance limits on the CRU or decryption system. Different portions of the content can also use different levels of protection. For example, relatively weak security can be applied to most of the content but much stronger protection can be applied to a small fraction of the material.
Content providers should change rights keys periodically to ensure that users who have lost their authorization cannot access content. For example, if a user terminates a subscription, the CRU may continue to operate unless the rights key is deleted/disabled or mechanisms outside the CryptoFirewall disable access. Content providers can limit the maximum duration of such use by making rights keys expire periodically (e.g., hourly, daily, weekly, monthly, annually, etc.) To ensure that key changeovers do not disrupt legitimate viewers, new rights keys can be distributed before the old ones are discontinued. During the changeover period, content can also be broadcast with KDMs that can operate using both the old rights key and the new one. An additional option is to queue the REM that updates the key until the key change is required. (Such queuing can be done by the playback device, ICP, etc.)
The memory technology used for nonvolatile protected memory does not need to be conventional EEPROM. For example, PROM, flash memory, battery-backed RAM, FeRAM, etc. all provide nonvolatile storage. Embodiments can even use hard drives or other media-based storage systems, although such approaches are generally infeasible due to their high cost and the difficulty of adding sufficient physical security. (Variants where a hard drive, or a portion of the hard drive, is protected can be useful in environments where the data itself must be stored and protected in the CRU.) Volatile protected memory can also be implemented using a variety of techniques, including registers implemented using standard logic, SRAM, DRAM, etc.
Although it is strongly preferable that values stored in the protected memory be cryptographic keys of sufficient length and quality to prevent attacks such as exhaustive search, it is possible to store shorter values. In one extreme case, individual bit flags that correspond to access rights can be stored in the protected memory. Valid REMs cause the CryptoFirewall to set and/or clear rights bits in the protected memory. When producing content decryption keys, the CryptoFirewall tests the value(s) of rights bits (or incorporates these bit values in the cryptographic transformations) so that valid content decryption keys are only produced if the appropriate bit(s) are set. Such embodiments, although possible, involve more risk because invasive attacks will tend to have more severe consequences.
The components of the CRU do not need to be connected by a bus. In fact, eliminating the bus and directly connecting components can have the advantage of increasing the effort required for physically-invasive attacks as buses can be attacked using (for example) microprobing techniques.
CRUs can contain any number of batch keys or device keys. Also, batch keys do not need to be assigned sequentially during the manufacturing process. (In fact, shuffling key assignment can be beneficial to make it more difficult for attackers to obtain cards with identical batch keys.) Batch keys (and other keys) also do not need to be static; they can be replaced or updated using, for example, a key update process such as the one described with respect to
Techniques such as those described in "Tracing Traitors" by Benny Chor, Amos Fiat, and Moni Maor (Advances in Cryptology—Crypto '94, Springer-Verlag, August 1994, pp. 257–270) can be used to identify the source of rebroadcast keys. The CRU can also encrypt content decryption keys, for example using an RSA public key corresponding to the playback device's private key or, preferably, using a unique symmetric key shared between the CRU and the playback device added during manufacturing. Such techniques can help prevent key redistribution attacks that involve using keys produced by one CRU in many playback devices. If the CRU has sufficient I/O bandwidth and computational speed, it can decode the content itself.
The pseudoasymmetric transformations can be implemented using (or replaced with) a variety of cryptographic operations. Methods for building randomly-constructed logic operations are described with respect to
Although it is generally simplest to have the interface control processor determine which memory addresses to use when storing and using rights keys, addresses can also be chosen by the CryptoFirewall, by the content provider, by the playback device, etc.
If errors occur in the CRU or CryptoFirewall, a failure counter can be incremented and, if the failure counter reaches a threshold value, the CRU may trigger an audit or cease to work. Examples of failures include torn operations (i.e., where processing is interrupted, for example due to a power loss), invalid commands (e.g., where invalid addresses are supplied), attempts to perform excessive numbers of transactions, and incorrect cryptographic parameters (such as failed attempts to clear post-payment audit records).
Communication processes do not need to be real-time. For example, an auditing process can work as follows: The CRU first receives a message broadcast with some content that initiates an audit. The CRU then outputs audit data to the playback device, which queues the data. Next, the playback device sends the audit data to the content provider, for example by broadcasting it using low-speed radio communication. After verifying the audit data, the content provider finally sends post-payment clearing commands with new content broadcasts.
Some steps, such as address verification by the CryptoFirewall, are recommended but may be omitted as they are not always essential. Steps can also be substituted with other operations that are functionally similar. For example, address verification can be performed by forcing invalid addresses to valid values (e.g., by setting or clearing bits in the address to ensure that the address is in a proper range and aligned appropriately). Many steps can also be reordered. For example, the chip-specific portion of the computation described with respect to
The pseudoasymmetric function generator (and functions it produces) can be used in applications other than content distribution. For example, stored value cards, electronic transit passes, software copy protection, challenge-response authentication tokens, and other applications where low-cost devices must carry secrets can all benefit from secure cryptographic transformation circuits that are difficult to reverse engineer.
The CryptoFirewall can include multiple cryptographic algorithms, some of which can be specific to a given CryptoFirewall or batch, and others that are more general. For example, in a large system with 25 million CRUs, it may be advantageous to minimize the consequences if any individual CryptoFirewall is reverse engineered. As a result, groups of (for example) 100,000 CryptoFirewalls may be constructed with different algorithms. KDMs and/or REMs are transmitted separately to each of the 250 groups.
Any components that include microprocessors can receive code updates. For example, code in the playback device, ICP, or the CryptoFirewall can be updated by the content provider. Code updates should be cryptographically protected (e.g., with digital signatures, MACs, etc.)
To ensure that interrupted memory updates do not compromise security, the CryptoFirewall can store memory update data and addresses in a pending-write buffer, set a write-pending bit, perform the write, then clear the write-pending bit. If the write operation is interrupted (e.g., due to a loss of power), the write will either be lost completely or can be completed from the pending buffer when the device is reset. Write operations can be verified to detect errors. Checksums or other verification fields can be included in stored data to detect memory corruption.
All of the foregoing illustrates exemplary embodiments and applications, from which related variations, enhancements and modifications will be apparent without departing from the spirit and scope of this patent. Therefore, the rights under this patent should not be limited to the foregoing disclosure, but rather construed by the claims appended hereto.
Patent Citations
Non-Patent Citations
Referenced by
Legal Events
Original Image


text:
Jose Mourinho wants you to believe he chose Chelsea over Manchester United
Jun 16, 2013, 9:06 AM EDT
Do you believe that Jose Mourinho took himself out of the running to succeed Sir Alex Ferguson at Manchester United?
Because that's what 'The Special One' hinted at earlier today when discussing Ferguson's retirement. Seemingly eager to reassure Chelsea supporters that his allegiance has always been with the Blues, Mourinho claimed that he knew of Sir Alex Ferguson's retirement "many months" before it happened and that he told the United legend that he wanted to return to Chelsea.
Leading up to United's announcement that former Everton manager David Moyes would be Ferguson's replacement, there was mass speculation that 'The Special One' could be headed to Old Trafford. Not only did Mourinho possess a stunning resume but he and Ferguson have long been known to be close friends, the result of a many a post-match discussion over a glass of wine or a few sips of whiskey.
"I knew that Ferguson was retiring many months ago, and I am so happy with his trust because it was big news for the world – I can imagine that just a very small circle around him knew that, and it was a big responsibility for me to know that," Mourinho said proudly.
It was Ferguson's decision to share the secret with Mourinho that compelled the Portuguese manager to share one of his own. "Why do I know that?" Mourinho asked. "Because we are friends, so if I am his friend to know that he is going to retire, he is also my friend to know that the club I want to coach in England is Chelsea. Of course I told him I want to come to Chelsea."
Some interesting soundbites by Mourinho, no doubt.
At the very least the Chelsea manager wants to remind us how close he is to Ferguson. Legendary managers roll with legendary managers. And make no mistake about it, Mourinho will forever be concerned with his place in footballing history (regardless of the fact that he's already secured his place as one of the greatest managers of all time).
But this isn't merely Mourinho's way of reminding us that he and Ferguson are thick as thieves – it's also his way of trying to undermine Moyes. It's Jose's way of letting Moyes know that, despite the fact that he wasn't hired to fill the post, he knew all about it well before Moyes.
Mind games, my friends. Jose loves them.
But even more than mere mind games, Mourinho said these things to protect his reputation by letting everyone know that it was he who denied United and not the other way around.
"I would have turned down every job in the world, the Manchester United job, everyone, for Chelsea I would turn down every job in the world," Mourinho said.
So there you have it, folks. Jose turned down United.
Or so he says.
- footballer4ever - Jun 16, 2013 at 1:17 PM
As "tempting" Mourihno may have been to MUFC, he sure carries a lot of baggage and garbage with him and the last thing a WORLD reknowned, respected, admired football club like MUFC is an unstable or drama driven manager. Of course, he is going to say he chose Chelsea over MU because his ego won't let him say otherwise.
Top Posts
- VIDEO: Watch Arsene Wenger snub Jose Mourinho handshake. Who is in the wrong? 0
- Cristiano Ronaldo buys his agent a Greek island… as a wedding gift 1
- Premier League friendly roundup: Southampton draws, Stoke swallowed 0
- Jose Mourinho says "best team lost," attacks Arsenal's defensive tactics, as Chelsea beaten at their own game 6
- Arsene Wenger, Jose Mourinho fail to shake hands, as Gunners boss finally prevails 1
- Three things we learned from Arsenal's Community Shield win vs. Chelsea 0

subset: commoncrawl


text:
Has anyone discovered how to get Process Tamer to be able to control processes which are run by the IUSR_SERVER user which is the anonymous internet user. I have processtamer running as a system service, so under the SYSTEM user, which i would have thought would be able to change the priority of those processes, as it is able to change the priority of processes running as Administrator.
PT is running as SYSTEM, and works well with other processes running as SYSTEM. If a process is running as ADMINISTRATOR its process priority is modified initially, but if it gets changed for whatever reason, it is not automatically reset to the priority PT is meant to force it to. Is there a reason for this? With processes running as SYSTEM, if their priority is manually changed, PT will automatically force it back to the set priority.
I am also unclear as to whether it is meant to be able to alter the priority of processes running as NETWORK SERVICE.
Any thoughts on any of these?


text:
Dino Trnka
Anime Info
If you like Japanese animation, this is the perfect app for you! Anime Info is a powerful and easy-to-use app which uses data from AniDB, a comprehensive anime database counting over 8300 anime titles. With Anime Info you can easily look up basic anime information, release dates, ratings,...
Steganography Master
Have you ever wanted to hide a secret message inside a photo? With Steganography Master, you can encode a message in a picture and then save it or send it to a friend. The message can only be decoded using the same app, but if you want to ensure that only the intended receiver can read the...


text:
Under Armour is prepared to jump into the heavily contested field of fitness monitoring with its Armour39 system.Armour39 consists of a sensor-equipped strap worn around the chest (or right below it); it includes a center sleeve for a "bug," which acts as a computer in storing and moving fitness data to the cloud via Bluetooth. Users can check their progress on a watch or by way of an app on the smartphone. The system will be available on March 20. The strap and bug will cost $149.99, while the optional watch accessory will cost $199.99. In moving into this field, the sports apparel manufacturer will take on large companies such as Nike and its
With Apple potentially getting into the business with the rumored iWatch, some believe the already growing market may take off even further in the coming months.
Under Armour, however, told CNET that an Android app would be coming shortly after launch.
For some of these companies, including Nike and Under Armour, these devices represent a marked departure from their core business. Neither are known as hardware companies, and Nike has had to prove itself with the FuelBand, which generally got strong reviews for its design and features.Of course, Under Armour itself shot up from seemingly nowhere. The company, founded in 1996, was a fledgling maker of fitness clothing and now stands alongside brands such as Nike and Reebok in the sports world, and is easily visibly at events such as the Olympics and in National Football League games. Armour39 was part of a larger presentation by Under Armour, which also unveiled the launch of a massive "brand house" in Baltimore, a new "I will" campaign, new cold wear, as well as the tease for a new shoe that won't be manufactured in a factory, but will "clothe your feet." While Under Armour has a lot of momentum behind it, the company still has an uphill climb in its attempt to breach the already crowded fitness-monitoring market.


text:
The Department of Defense announced today the death of a Soldier who was supporting Operation Iraqi Freedom.
Pfc. Thomas D. Caughman, 20, of Lexington, S.C., died June 9, in Baghdad, Iraq when his up-armored high-mobility-multi-purpose wheeled vehicle was struck by rocket propelled grenades and small arms fire. Caughman was assigned to the Army Reserves Company C, 391st Engineer Battalion, Spartanburg, S.C.
The incident is under investigation.
For further information related to this release Army Public Affairs at (703) 692-2000.


text:
Roller Derby
By hard-hitting, booty-blocking skaters
Posts filtered on Tag
AASRD Brawlstars take on Pair O' Dice City Rollers This Saturday!
Saturday is bout day at the Washington Avenue Armory as the Albany All Stars B-team, the Brawlstars, take on Pair O' Dice City Rollers from Wilbraham, MA. Welcome to the Pair O' Dice Rollers: and now…introducing your Albany BRAWL stars! Doors opens at 6pm– come cheer on your Albany All Stars! For more info on Pair […] [Read More]


text:
Buck Harvey on Sports
Between columns, Buck discusses the major developments in sports and what's on his readers' minds.
Monthly Archive for October, 2012
Presti trades his Manu
Russell Westbrook is the star. He flies toward dunks, and he shoots as if he is Kevin Durant's equal, and there haven't been many point guards in history like him. Sam Presti weighed all of that when deciding who to keep and who to trade, and maybe Presti remembers Game 5 in San Antonio last […] [Read More]
Nike rules — strongest verdict against Lance
Lance Armstrong fell Wednesday. And it wasn't to the Feds. Or to "60 Minutes." Or even to the U.S. Anti-Doping Agency. Armstrong fell because Nike quit believing in him, and nothing he's faced — including those who testified against him — had as much credibility. Others talked, but money did this time. What the USADA […] [Read More]


text:
Run/Walk Join us in promoting healthy lifestyle choices within the Paradise Community while having fun! Prizes awarded to top runners and teams. Free registration for children under 12 with adult registrant.
Race Course The 5K timed run follows the walking path starting from the park gazebo at Pearson/Black Olive Drive and runs uphill towards Bille Rd. (following the bike path). Racers turn near Bille Rd. and head back to finish at the gazebo. Be inspired by the beauty; be challenged by the uphill course.
Activities The prevention fair includes activities for the whole family that show how simple lifestyle changes can improve your health. Participate in our live fitness demonstrations, enjoy music and visit our experts to learn fun ways to eat well and get exercising. • Free vision screenings • Exercise & fitness demos • Flu shots • Giveaways & healthy food samples • Raffle drawings
Help up get the word out - Click here to print and display event poster
>> Register online at Active.com
Participate as a Corporate Team OR a Family Team - Download a Team Reg Packet
Join us in promoting healthy lifestyle choices within the Paradise Community while having fun! Get together 3 or more people and form a TEAM. Compete with other teams for prizes and recognition.
Prizes for top teams!
Registration Register online at Active.com. To register by mail, complete registration form and mail with payment as indicated. For additional information or to register by phone contact the Diabetes Education Department at 530 876-7297 or email us at email@example.com
Event Sponsors This event is co-sponsored by Feather River Hospital Diabetes Education and Employee Wellness Programs and Lions Club of Paradise. Proceeds benefit our Diabetes Education and Scholarship Fund.
Diabetes Educational Services (DES) has established this website to provide information and education to health care professionals. Nothing in this website constitutes medical advice nor is it a substitute for medical advice. References in this website to any and all specific products, services or processes do not constitute or imply an endorsement or recommendation by Diabetes Educational Services.


text:
The beating death of Florida A&M University drum major Robert Champion is forcing school administrators to take a hard look at how they deal with the culture of hazing, especially among the famed Marching 100 band.
Though FAMU already has a firm policy against the practice — band members are forced to sign an anti-hazing pledge, scores have been suspended through the years and others have been arrested recently — it has become clear that a lot more must be done to root it out.
In the weeks since Champion's death, the FAMU board of trustees has moved to create an anti-hazing committee. One place it might turn for ideas: other universities that confronted similar tragedies, then worked hard to change the culture at their schools.
Sadly, Champion's death is no isolated incident.


text:
Equipment Technology
» Precision dispenser
Technical Library
Robotic assistant for TMS
Laboratory taxi
Tattoo machine
Surgical vision systems
ViKY system
Blood pressure measuring
Drug Dispenser
Diagnostic and therapy capsules
Controlled Prosthetic Leg
Blood Circulation Scanner
Medical lab diagnostics
Blood glucose meter
Miniature Hexapods
Medical & Lab Equipment
Condor Sigma test device
Electric field meters
Measuring system
Stripping machines
Horizontal Balancing Machines
Precision dispenser
Dial Gauge Testing
Ring shear tester
Equipment Technology
Industrial robots
CHIMP robot
Recon Scout IR
Guardian MROV
Humanoid servíce robots
Robotic Arm
Robotic Hand
Robot Vehicle
Pick-and-place Machines
Manufacture robotics
Sewer Robot
Shrimp Vehicle
Belt conveyors
Swivel unit
Factory Automation & Robotics
5-axis CNC unit
Adaptive Wire Feeder
Solar wafer production
Window Wipers
Weighing System
Linear positioners
Pressure pulsations
Laser welding
Printing machine
Cutting Plotter
Industrial Tools & Equipment
Electromechanical lock cylinders
Security & Communications
Microscope Scanning Stage
Giant telescope
Panoramic camera
Camera set up
Reconnaissance Drones
Drive-in cinema
Live Camera Systems
Camera Cranes
Audio, Visual & Data
1,9 mm Micromotor
Water dispenser
Tabletop soccer
Cigar humidification system
Commercial Vehicle Replicas
Spherical Vehicle
Model steam locomotive
Football robot
Modelling & Prototyping
Energy kites
Camera head inspection devices
Micro annular gear pump
Deep-Sea Sensors
Environmental & Safety
Control rocket fuel valves
Measuring sensor
Comet probe / Rosetta
Aerospace & Aviation
Exhibitions & Events
Jobs & Careers
Contact & Catalogue
0.001 ml of fluid precision-dosed
Miniature drive powers conveyor rotor in precision dispenser
Small is "in". As a consequence, the spread of miniaturization in automation is leading to ever increasing demands for optimum dosage of the tiniest quantities. Whether in electronics or micromechanical engineering: solder pastes, adhesives, lubricants, potting and sealing compounds have to be applied precisely where they are needed, in exactly the right dosage, with no spillage or dripping. Precision volume dosage units are the method of choice when high flexibility allied to exact application is essential. In line with their usage, units of this type also have to be extremely compact. So miniature drives are the most suitable power source for them. They deliver high performance in a compact design, and are highly dynamic as well as precisely controllable – both attributes which are essential to a dosage unit.
Automatically dosing small quantities in a targeted way is no trivial matter. In fact, it demands detailed know-how and innovative strength. The specialist in precision volume dosage under the brand name preeflow®, ViscoTec Pumpen- und Dosiertechnik GmbH based in Töging am Inn, Upper Bavaria, offers both of those qualities. So as not to be continually reinventing the (drive) wheel, the dosage specialists turned to the drive experts from FAULHABER. Together, they quickly devised a robust, precise drive solution for the dosage units.
Volumetric dosage
There are a number of possible methods of dosing ultra-small quantities. Dosage by volume has proved the most simple and flexible method in practice. The substance being transported "only" has to be brought to the dosage tip by constant-flow pumps. The desired quantities are then delivered based on the known delivery quantity and time. Of course, here as in many tricky tasks, the devil is in the detail. Factors such as differing viscosities, abrasive or more smearing substances, elasticity, tendency to drip etc. must be taken into account when designing the dispenser unit. In the eco-PEN, those and other criteria are met on the basis of practical experience. The heart of the dispenser unit is a rotating, absolutely pressure-tight positive displacement system, comprising a self-sealing inner rotor and the outer stator. A controlled rotary motion of the rotor transports the medium by positive displacement. A reverser also permits the system to transport backward. This enables neat, controlled material separation with no dripping. The medium itself is transported in a non-harmful way, without altering its structure. The system is designed to be self-sealing with water up to 2 bar delivery pressure. As the viscosity increases, so does the self-sealing effect. This makes it possible to achieve dosage pressures of 16 to 20 bar without problem. This high delivery pressure in turn permits the use of smaller needle and nozzle cross-sections for finer application areas. It is also possible to apply a basic admission pressure for high-viscosity media. This means that no pressure tank is needed for self-levelling fluids. In this way, 0.15 to 16.9 ml of medium per minute can be continuously transported with just three models. If point dosage is required, a minimum quantity of 0.001 ml, 0.004 ml or 0.015 ml can be precision-placed, depending on the model. For improved maintenance and cleaning when changing media, the volume dosage units are modular in design – comprising a drive unit and the actual dispenser unit, with a separate controller for the drive.
High-torque drive
The high possible delivery pressure in the dispenser module of course means a high-torque drive is essential. Given the restricted size of the unit, the only feasible option is a miniature motor with a gearhead. Working with FAULHABER, the designers quickly found the right mini powerpack for their needs. The best value for money was offered by a brush motor with an encoder and planetary gearhead. The brush commutation provides for easy pulse width regulation and reversing. Fitting the encoder and planetary gearhead within the motor diameter allowed the design to be kept slim. The gears and motor bearings are lifetime-lubricated and maintenance-free. The integrated encoder enables precision quantity dosage and drip-free separation of the medium based on exact feedback of the drive rotor position. The gear reduction improves this resolution on the conveyor rotor of the dispenser module still further. The compact drive block, comprising the motor with the encoder and gearing, is just 22 in diameter, depending on dispenser model, while the motor is 32 mm long and the gear length is 27 to 48 mm (9 to 23014:1). The "big brother" is 26 mm in diameter and 42 mm long, with gear length from 28 to 60 mm (3.7 to 1526 :1). The motors deliver 10 mNm of continuous torque at 6 to 24 VDC, with the big ones delivering 28 mNm at 12 to 48 VDC. This torque is increased as necessary by the specific gear to the level necessary for the dispenser unit at 20 bar delivery pressure. The plug-in encoder delivers 64 to 512 pulses per revolution depending on type, so in conjunction with the gear unit this produces a fine resolution of the conveyor rotor position. A custom cable connection feeds the operating voltage and encoder signal to the control unit. Miniature drives are a space-saving alternative for many of today's drive applications. Power and size adapted gears and encoders are also available, enabling the drive to be integrated easily into many systems. The drive often replaces expensive, maintenance-intensive mechanical transmissions on site, or indeed makes a design concept feasible in the first place thanks to its compact size.
More information you can find under
Targeted medium application with the
eco-PEN dispenser unit from ViscoTec


text:
The Free Slots
Free Bingo Bonuses
Get exclusive free slots bonuses delivered directly to your inbox!
Slots Capital Casino - No Deposit Bonus
Bonus Details: $15 free no deposit bonus at Slots Capital Casino!
$15 Free Slots Bonus
No Deposit Required
Redeem Bonus Code NCP15SC
TheFreeSlots.com exclusive offer!
Slots Capital Casino is a relatively new Rival powered online casino that accepts players from around the world with the exception of players from the United States and Canada. They have hundreds of great games to choose from and for a limited time you can try them out for free by taking advantage of our exclusive free slots bonus! Simply redeem our special bonus code NCP15SC and youll instantly receive $15 in free slots money that you can use to play all of the great games that Slots Capital Casino has to offer!
Latest Free Slots Bonuses
Grand Parker Casino
$25 Free
Loco Panda Casino
$25 Free
WinPalace Casino
$150 Free
Slots Jungle Casino
$30 Free
Slot Madness Casino
$50 Free
Royal Ace Casino
$50 Free
Platinum Play Casino
$1500 Free
Jackpot City Casino
$25 Free
Golden Cherry Casino
$333 Free
Vegas Casino Online
$20 Free
© 2012 The Free Slots
TheFreeSlots.com features free no deposit casino bonuses that you can use to win real money!
Disclaimer: This website is an informational site and should be used for informational purposes only. We pride ourselves on having the most up to date information but cannot guarantee 100% accuracy. Please check your local laws regarding online gambling to ensure that you are in compliance with the laws of your jurisdiction.
The Free Slots
Free Bingo Bonuses


text:
List Price $10.00 Save $2.05 (20%)
Want it delivered 08-06-2015?
Order it in the next 18 hr and 3 min and choose Next Day Air Morning at checkout. Details
Average Customer Review4.5 (25 reviews)
Create an online reviewand share your thoughts with other customers
Things I liked:great pellets, good quality
Things I would have changed:none
What others should know:great pellets, accurate
Things I liked:The looks and how they perform. Thes and the H&N Baracuda Huner extremes are now my regular serious shooting pellets.
Things I would have changed:Only larger quaniyies.
What others should know:I just tested these on 2, 1 gallon plastic milk jugs filled with water with both my Beeman RS2 and my Benjamin Titan. Both almost shot through both jugs. The pellet showed some deformation but not much. They did remain stable completely through their path through the water jugs. I believe they would remain pretty stable on their path through game as well. Of course game would have hide and bone that the water jugs don't. I will never be without several hundred of these pellets and only one place to get them ... PYRAMYD!!!
I recently shot a squirrel at fairly close range (12-15 yards) with my Benjanim Titan using these Spitskugel 15.74 gn. pointed pellet. The squirrel was on top of my storage shed sitting on his haunches (typical squirrel stance) and the pellet struck him just behind (or in this case low) of a text book heart/lung shot. He showed very little reaction to the hit, certainly way less than I expected. He jumped a bit then ran to the big pecan tree by the shed. I looked for him a bit before I found him about 6-8 fet up the tree in a large fork of the tree. He was pretty well anchored. A few shots from my M&P 40 knocked him out of the tree. Apon examination he showed visible entrance and exit wounds. Not real big, but clear. I suspect that the pellet missed any ribs or other bones and that accounts for why he showed so little reaction to the hit. Still, he only went a very short distance so it was basically a clean kill. This is the first kill on a squirrel or rabbit that was not instantanious using these pellets. These are very high quality pellets that are very accurate and kill very effectively. One of my regular pellets most used in .22 cal.
Things I liked:Best pointed pellet,hard hitting.
Things I would have changed:Size needs to be a little bigger to fit the barrel tighter.
Show Other ReviewsCreate an online review and share your thoughts with other customers
Compatible with H&N Spitzkugel Pellets, .22 Cal, 16.05 Grains, Pointed, 200ct
CheckoutSubtotal (USD):
does not include shipping and tax