WO2015012782A1 - Dynamic obfuscation processing - Google Patents

Abstract

An automated tool builds a plurality of uniquely paired data source and data receiver programs by identifying and modifying data or program instructions on the data source processing and identifying and applying reversing modifications on the data receiver such that the uniquely paired data apply and remove the same process modifications. In one example a paired data source and data receiver program is periodically replaced by another paired data source and data receiver program having different modifications than the pair being replace. In another example, modification data to a program or process is loaded after the program is process is built allowing for dynamic updates to the data modifying the process data or instructions or both.

Description

Title: Dynamic Obfuscation Processing

CROSS-REFERENCE TO RELATED APPLICATIONS

The present Utility patent application claims priority benefit of the following U.S. provisional applications 61/286,904 titled Client Unique Security Processing filed Dec 16, 2009, application 61/290,617 titled Client Unique Security Processing filed Dec 29, 2009, application 61/248,480 titled Dual Layer Encryption Content Security filed Oct 4, 2009, application 61/317,662 titled Simulcrypt Security Enhancement filed Mar 25, 2010, application 61/242,438 titled Advertising

Management Security System filed Sept. 15, 2009, application 61/332,352 titled Security System with Multiple Secure Processors filed May 7, 2010, application 61/306,545 titled Dynamic CAS Security filed Feb 21, 2010, application 61/421,066 titled Secure Encoder filed Dec. 8, 2010, under 35 U.S.C. 119(e). The contents of these related provisional applications are incorporated herein by reference for all purposes.

FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

Not applicable.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or patent disclosure as it appears in the Patent and Trademark Office, patent file or records, but otherwise reserves all copyright rights whatsoever.

FIELD OF INVENTION

The present invention relates generally to computer security, algorithm development, and software obfuscation. More particularly, the invention relates to the creation, management, and execution of unlimited modified software codes used for security and obfuscation of the processing.

BACKGROUND OF THE INVENTION

In security technology the use of secure algorithms with known security properties such as the Advanced Encryption Algorithm (AES), or RSA based Public/Private key cryptography (PKI) are combined with processing logic that is fairly static and intended to be used for months or years. However, the application of a known algorithm such as AES or Diffie-Hellman, or RSA PKI provides adversaries with information that can be used to compromise the security of a system.

US Patent 7,512,986 issed to Shen-Orr et al provides a different version of client unique processing wherein long keys are used with client unique processing. US Patent 5,742,681 provides degraded video viewing using different entitlement ECM packets.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:

Figure 1 is an example of an algorithm structure in accordance with an embodiment of the present invention; Figure 2 shows the processing flow for a tool that automatically modifies code; Figure 3,4, and 5 shows the output data values for standards based processing and two instances of dynamic format processed data; Figure 6 shows dynamic format processed data with initialization vectors; Figure 7 shows a simplified processing block; Figure 8 shows the simplified processing block of Figure 7 with input and output dynamic format processing; Figure 9 shows decode process frame storage processing with dynamic format processing on address and data paths; Figure 10 shows dynamic and static code portioning; Figure 1 1 shows dynamic format processing code applied to an encode process; Figure 12 shows dynamic format processing being applied to partially decoded standards based data; Figure 13 shows a replaceable security core; Figure 14 shows standards based encryption with unique software encryption. Figure 15 shows content with a decryption key in the content;

SUMMARY OF THE INVENTION

In an example embodiment of one element of the invention, the message format of a 'standards' based processing function such as an MPEG-2

encoder/decoder, or an H.264 encoder/decoder has data and processing modified creating a non-standard version and preventing the use of a standards based decoder/encoder. One element of this invention creates millions of versions of the processing derived from standards based processing (e.g. encoder/decoders). The modified versions have the same inherent benefits of the product it modifies, such as encoding and decoding, but the modified versions outputs data that cannot be readily shared by other versions of the encoder/decoder. Furthermore, the internal processing and data format output by the modified version in one example is different than the message formats or internal processing defined by standards such as MPEG-2, H.264, and other standards commonly used in computers to allow the interchange of data between different computers, networks, operating systems, etc.

In another example of one embodiment, any form of computer algorithm is modified into a number of derivative algorithms with each algorithm having different internal data processing, different algorithmic strength, and input/output data when compared to other algorithms derived from the same starting algorithm. For example, a standard AES encryption/decryption algorithm is modified in one or more different ways with the resulting modified AES code potentially having weak keys, and the algorithm compromised when compared to the standard AES algorithm. In yet another example of one embodiment, the security processing combines an unmodified version of an algorithm with known strength such as AES or 3DES with modified versions wherein the standard version of the AES algorithm provides an algorithm with known strengths while the second modified version of the algorithm obfuscates the processing preventing the system from being compromised by obtaining a single key (e.g. the standards based AES encrypt/decrypt key).

In this patent application video encode and decode processing is being used as an example of the enhanced processing steps provided by this invention, however the inventive processing steps can be applied to any type of data or processing including but not limited to audio, video, computer data, encryption, communications device data, USB stored data, hard-disk drive data and processing, and data and processing of any type.

In yet another example of one embodiment, common key sharing forms of piracy such as control-word sharing attacks to Digital Video Broadcasting (DVB) an other content or data delivery systems is prevented by the application of non-standard based algorithms that force pirates to reverse engineer the algorithm to be able to compromise a system.

Other features, advantages, and objects of the present invention will become more apparent and be more readily understood from the following detailed descriptions, which should be read in conjunction with the accompany drawings.

DETAILED DESCRIPTION

The present invention is best understood by reference to the detailed figures and descriptions set forth herein.

Embodiments of the invention are discussed below with reference to the Figures. However, those skilled in the art will readily appreciate that the detailed descriptions given herein with respect to these figures is for explanatory purposes as the invention extends beyond these limited embodiments. For example, it should be appreciated that those skilled in the art will, in light of the teachings of the present invention, recognize a multiplicity of alternate and suitable approaches, depending upon the needs of the particular application, to implement the functionality of any given detail described herein, beyond the particular implementation choices in the following embodiments described and shown. That is, there are numerous modifications and variations of the invention that are too numerous to be listed but that all fit within the scope of the invention.

Figure 1 shows a simplified example algorithm in the form of two rounds of an encryption/decryption algorithm. Figure 1 is used to illustrate one or more of the modification steps applied to an algorithm of any form, and an encryption/decryption algorithm is used for illustrative purposes. Any one or more of the processing blocks in Figure 1 are modified in various different ways by an algorithm modification routine call CryptoBuilder. While the name CryptoBuilder implies cryptographic processing the CryptoBuilder processing steps and modifications can be applied to any logic processing for cryptographic processing (encryption/decryption, security processing, Digital Rights Management, key processing, etc.) and non-cryptographic processing of any kind (encoding/decoding, protocol messaging, control logic, state machine design, and any other software techniques.

In a standards based encryption algorithm plain text 1310 enters the encryption 1305 process and is processed sequentially resulting in cipher text output 1330. Software tools of any type (C, C++, C#, assembly language, Java, Basic, Javascript, shell scripts, Fortran, Cobal, etc.) are used to code (define) the programming sequence for the encryption/decryption in Figure 1.

In this patent application the terms CryptoBuilder, Dynamic Function Processing, and CAS Builder are used to describe one or more processing techniques and

combinations of processing described for any one of the elements individually can be combined. Any one or more of the processing steps are modified by creating a software tool called CryptoBuilder or Dynamic Function Processing (DFP) or CAS Builder that modifies the internal processing code or data tables for any one or more of the pieces used to compose the processing logic. One or more processing steps that will be modified by Cryptobuilder are identified to CryptoBuilder (CB) and CB processing will apply processing step appropriate modifications contained in the CB program. Cryptobuilder in one example is shown as an automated software tool that modifies an input program producing a different version with different processing than the input source. As such, CB actually changes the way the algorithm or program operates. Figure 2 provides an example of the high-level program flow for CB. In Figure 2 code elements that will be modified are identified in the source code in step 202, examples include but are not limited to data tables such as S-Tables, P- Tables in the Blowfish algorithm, processing blocks, code sequences, code layout (order of functions or sequence of code), sequencer state tables, virtual tables, and other code, identifiers, or data structures associated with the source material input (source code or script code or other). Reference source code for a particular processing (encryption/decryption, encoding/decoding, control logic, other processing) is used with sections identified that will be modified using CB/DFP tool.

In step 204 the source material (e.g. unmodified source code) is read by CB. In step 206 CB applies a change to the source material by locating an identified piece of code by its function name, label, data offset, reference, location, or any other type of direct (label) or indirect (offset) (for example, S-Table, or P-Table, or Shift_Rows() or Table[18], etc.) and CB modifies the identified source using text substitution, data shuffling or reordering, or data modification, or sequence modification, or a combination of any modification method for the source material being modified. In one cryptography related example the substitution and permutation tables are modified, and in a second the processing of the internal algorithms are modified, and in a third the number of processing rounds associated with the algorithm are modified and in a forth the sequence flow is modified such as performing an additional shift- row or nibble substitution, and in a fifth a binary mapping table is applied to the processing, etc., etc. It should be appreciated by one skilled in the art of software development that an unlimited number of modifications can be applied to the source material.

In step 208 CB determines if all the required changes have been made and if so the code outputs the modified version in step 210, otherwise CB loops back applying one or more identical or different changes to the source material in step 206. The changes applied in step 208 can be pre-determined as is the case of applying algorithm or programming step changes, or they can be random as in changing algorithm data tables or variable including but not limited to loop variables, hashing data tables creating new version unique tables, modifying sequence flow, transforming data or variables used in the processing, and other data, instruction, or combined

modifications applied to any of the processing in the source input. In another example, random code chains (to be explained later) are added to the processing further obfuscating the output code by having unique code chains added to the processing in addition to, or in place of any other data modification steps. Any programming tools or programming methods can be used to implement the CB process including but not limited to C, C++, C#, Python, Ruby, Java, Javascript, etc.

After CB modifies the source material further processing such as compiling or testing the code may be performed if necessary but not shown in Figure 2. One example where such further processing is not necessary is for scripting languages where CB/DFP processing modifies a script that does not require compilation. Step 212 associates a version ID with the output code providing a unique identifier (ID) for this version of modified code. The Figure 2 process is repeated for the number of desired versions using one or more different modifications to each modified version of the starting source code. For example, if there are 10,000 versions of code built using the CB process than each one can have random data or processing or sequences such that they are not identical to another version. Any form of modification can be applied including transforming data with version unique data (hash of a version counter, transform function seeded by version counter, modified loop counts, randomizes mapping tables, etc.) In one example, a million subscribers on a service get a subscriber unique version of code compute as generated by the CB process. In another example, 10,000 versions of unique code is output by CB and executed by all the subscribers to a service with the versions changing every 4 hours. An important distinction between the CB process and standards based algorithms is that CB modifies the algorithm for both the sender and receiver of the data, and this is very much different than using a standards based algorithm on a Apple MAC personal computer and a Windows based personal computer. For example, 128 bit AES encryption/decryption processing is the same for all devices, whereas the output of CB will only be useful on the devices having the same algorithm modifications, and those modifications have to be made specifically for the devices using the appropriate development tools (compiler, linker, interpreters, etc.) for the two or more devices that may be using different operating systems, hardware, etc.

Referring back to Figure 1, Step 1312 applies a round key to plain text 1310. Step 1312 when chosen for modification by CB by identifying an element of step 1312 such as the function name, or a code label, or even a code sequence. When step 1312 processing is identified for modification, CB builds a version of step 1312 processing that is not the same as the 'standards' based processing or the input source version. Other processing steps ash shown in Figure 1 or data (not shown) or combinations can be modified. Figure 1 shows encryption process 1305 and decryption process 1355. CB will modify the appropriate processing steps in encryption process 1305 and decryption process 1355 such that encryption/decryption modifications are coordinated. Often the encryption process 1305 and decryption process 1355 will run on different hardware including different CPUs and hardware, different Operating Systems (OSs), different programming languages and program development tools. CB performs target (end device hardware, OS, etc.) modifications to one or more of the software development tools/environments required to properly build the tar based get device code. In Figure 1 Encryption process 1305 may run on an Intel x8 Windows server using C# development tools, while decryption process 1355 runs on a Linux based embedded STB using an ARM core. CB performs its modifications to one or more target specific software environment.

In another example, CB modifies the message data format making the message data unique on a per-client, or per-mission, or per-transmission/transaction basis. An example using MPEG-2 data is that a Group-of-Pictures (GOP) Start Code and other MPEG codes are modified from what is published in standards document such that standards based decoders cannot properly decode the messages. In this example, the GOP and other codes do not need to be encrypted but rather only modified from the standards defined value to something else. Modifications can be on any data format or data type including data and values of any length of bits. In another example, the message data value (e.g. GOP start code) is encrypted before being output and must be decrypted before being recognized as a standards based GOP code. Modification can be applied using a modification algorithm or adding modification data and programming steps to the processing or encrypting the values or any other form of modification can be applied. An important element of the modification is that they are reversible in the receiving device allowing for coordinated modifications to be generated by the data source (sender) and removed by data receiver. Reversible functions can be based on symmetrical or asymmetrical functions.

Another inventive element splits modifies the processing to require processing using two or more chips, or two or more processing paths within a single chip such that an adversary has to reverse engineer the two processing paths. Furthermore, the splitting of processing across multiple hardware circuits can be performed such that two hardware circuits are 'paired'. Pairing means that only chips containing the proper keys, or code, or modified code, or modified data will work with each other and substituting a non-paired (with different data or code) hardware circuit will not result in a system that processes data correctly.

Figure 10 shows an example of the inventive processing steps applied to a video encoder. In a video encoder core logic 110 performs encoder specific logic such as motion estimation, spatialcoding, temporal coding, predictive coding, filtering, signal processing (discrete cosign transform, etc.)., weighting, quantization, entropy and run- length, coding and other processing. Core logic 110 can be any type of processing. Normally, core logic 110 will output standards based data such that a standards based decoder can decode and display data.

In Figure 10 dynamic format processing (DFP) 115 (stage 1) performs encoder specific processing modifying the output from core logic 110. DFP uses similar techniques or identical techniques as the crypto-builder and is applied to general program logic (not cryptographic processing) and data messages and data formats and logic processing for any type of processing. Any and all of the discussions and examples regarding CryptoBuilder apply to Dynamic Format Processing and vice- versa. DFP applies transforms (one-way or reversible or both) to core logic 110 output such that standards based decoders cannot properly decode data output from secure encoder. Figure 10 shows DFP 115 Stage 1 output feeding an output format processing 120 stage that for an encoder will apply additional data compression such as Run Length Encode (RLE) or CAVLC, or CABAC data compression. Output format processing 120 optionally includes DFP 125 instead of, or in addition to DFP 115. Dynamic Security Processing 135 is an optional stage that adds encoder unique encryption combining standards based encryption algorithms such as AES or DES or 3DES, or Private/Public Key PKI based encryption with unique encryption algorithms. Output 140 is used to output encoder data to other system processing elements.

Dynamic Format Processing DFP can be added to any stage of processing internal or external to any existing processing and is shown external to core logic 110 but can be included in core logic 110 or at any other processing point. A single instance of the DFP processing can be added or multiple instances can be added to process.

The DFP processing applies any type of transform to the data. Transforms can be of any type that is reversible on the receiving side. For a system data source DFP processing in the device sourcing data (e.g. encoder data) must be reversible in the device receiving the data or the client (e.g. decoder device) so that the receiving client can recreate the core logic data output allowing the core logic data output to be recreated in the client (receiving device). However, the data being transported from data source (e.g. encoder) to data receiver (e.g. decoder) will be unique for the source/data pair, or for the group of devices sharing the same DFP processing. Data source can use public/private key encryption as part of the reversible functions for the DFP processing and the data receive will apply private/public key processing to properly decrypt source data. Give example with PKI, AES, unique algorithm based DFP in data source (encoder) and data receiver (decoder).

While the DFP processing is shown as a single block in the Figures, the DFP can be implemented as one or more processing code segments interwoven with core logic 110 processing code or other any other processing. For example, core logic 110 may consists of hundreds or thousands of lines of code and one or more DFP processing steps can be added in multiple different code pieces making up the core logic processing software. Optionally, one or more DFP algorithms can be embedded in the encoder/decoder with one of the plurality of algorithms being device specific and others being grouped to allow multiple decoders to decode the encoder output when the encoder uses the group DFP processing and not the unique DFP processing output of the encoder.

The DFP processing can be added on a per-client, per mission, or per transfer basic. Or, the DFP processing can be combined with the core logic and other processing software such that each piece of code (e.g. encoder) is unique at compile time, or when installed onto computer hardware.

In one example encoders produce encoder unique data and an encoder DFP identifier indicates to the receiving source the correct DFP processing that must be performed in the receiver (client) to properly decode the data. In another example, there is no explicit DFP identifier and the encoder and decoder(s) have the correct DFP processing embedded within them when the decoder is installed. This embedding of the proper DFP processing can use any technique such as compiled code, interpreted code, script code, data tables, sequencer tables, or any other technique). The encoder specific DFP code that must be added to the decoder (receiver or client) to properly process source data can be source code compiled into the decoder library, or object code linked into the decoder code, or a library downloaded into the client, or data tables stored in the clients hardware or software containing code or instructions (binary, object, script like code, java code, etc.) containing processing steps to properly apply decoder or receiver based DFP processing steps to properly decode data from the DFP enhanced data source (e.g. encoder).

Dynamic Security Processing (DSP) 135 uses encoder unique security processing including security algorithms and optionally unique encryption algorithms (modified AES, or modified 3DES, or modified PKI) to optionally encrypt the encoder data before outputting data from output 140. When DSP 135 is combined with one or more stages of DFP (113, 123, and other) someone intercepting output 140 will not know that the security encryption algorithms used are, and will not know how to decode the unencrypted encoder output. As such, the level of difficulty in decoding and correctly displaying the data is greatly enhanced. In this invention any descriptions and attributes associated with the DFP also apply to the DSP and vice- versa. Another element of the DFP processing is the addition of DFP-Sequence codes indicating to the decoder that segments or sequences of the encoders output is being modified to prevent known properties of the data from being identified. For example, in video, the transmission of an i-frame allows the decoder to resynchronize data display in the event there is data corruption. Hackers attempting to pirate content can look for the repetitive transmission of i-frames every second or so to gain insight into the video structure. The DFP-Sequence code indicates the correct key, IV, or code sequence that must be used to decode the following data sequence. Changing an IV, key, code sequence or other element of the processing masks the periodic

transmission of repetitive data preventing the hackers from easily identifying the repetitive data preventing information leakage about the repetitive data. While the above example showed video i-frame data, other periodic or identifiable data can optionally be masked by changing the DFP processing applied to the data. The optional DFP-Sequence code changes on basis such as every N-bytes (10, 100, 1000, etc.) bytes, or every N seconds, or changing between every ½ second and 2 seconds based on a random timer in the encoder, etc. The DFP-Sequence code is added to the encoder output indicating to the decoder the correct processing necessary for the next segment of data.

In addition, encoder output can be encrypted use one or more encryption techniques and optionally using a feedback mode of encryption that also helps to mask repetitive output data sequences (such as i-frames) that can be used by hackers to gain insight into the encoders operation . The feedback mode used can be based on changing key/algorithm using the DFP-Sequence code that can be used as an encryption Initialization Vector (IV) or seed, or an index into a mapping table (maps sequence data to keys, encryption modes/encryption feedback mode, or IVs, or algorithm seed, etc.)

DFP and/or DSP dynamic security processing can protect content processing elements such as a codec or graphic rendering code or frame buffer processing code such that a frame buffer scraper must change over time to work properly. Likewise, hardware binding (linking the security client to hardware) can also change dynamically forcing hackers to have to reverse engineer changing versions of client code. Dynamically changing memory mapping tables scramble memory such that hackers cannot use a single memory location or single data value at a known memory location to compromise a system. In addition, the actual frame buffers used for video content can be obfuscated using memory buffer mapping tables increasing the difficulty of hacking data. Frame buffer mapping tables can be changed on a per title basis or a during a title, or using the DFP-Sequence code or equivalent during display processing.

Dynamic code (CB, DFP, or DSP or CAS builder) includes a version indicator and client software allows the downloaded security code to execute on the client hardware. In one example, different code signing techniques are incorporated into the client code that change over time. A portion or all of the client security processing (client library) changes over time. Dynamic security code can protect content processing elements such as a codec or graphic rendering code or frame buffer processing code such that a frame buffer scraper must change over time to work properly. Likewise, hardware binding (linking the security client to hardware) can also change dynamically forcing hackers to have to reverse engineer changing versions of client code. Dynamically changing memory mapping tables scramble memory such that hackers cannot use a single memory location or single data value at a known memory location to compromise a system.

DFP processing (or data associated with DFP processing) can be split across two different hardware devices wherein for example, the hardware decoder contains portions of the DFP processing and requires contributions from a second hardware device such as a secure microprocessor in a smartcard, or data in a secure USB plugin device or other hardware.

Portions or all of the DFP processing can be designed into protected regions of hardware in chips wherein the actual DFP processing is obscured from view of the hackers by the protected hardware. In addition, the DFP processing can be loaded via an unsecure channel into the protected hardware such that the hacker intercepting the unsecure channel data being loaded into the protected DFP processing area cannot be used by the hacker without extensive reverse engineering work. Multiple versions of the DFP code are built using an automated tool referred to as DFP builder or CB or CAS Builder that coordinates the building of the encoder version of the processing with the decoder version of the processing. The encoder/decoder DFP process builder may use different tools and different tool chains/programming languages etc and coordinates the processing such that both the encoder and decoder properly process data regardless of the technology (compilers, interpreters, etc.) used in generating the DFP processing on each device

(encoder/decoder). DFP builder techniques can also be used to build DSP code. DFP builder modifies the DFP processing for each encoder/receiver. One encoder can support DFP processing for multiple unique decoders. One decoder can support DFP processing for multiple encoders. Any form of DFP code processing/storage/loading can be used.

Another element of this invention is that the DFP code for each encoder or decoder is unique for that encoder or decoder, preventing a hacker from exporting DFP code from one device and moving it to another without extensive reverse engineer. DFP builder includes hardware binding techniques to verify that the code or processing for the encoder or decoder (data source or receiver) cannot be easily ported to another device. Many forms of hardware binding can be applied wherein encoder processing uses encoder and/or decoder specific data, hardware identifiers, hardware keys during its processing that bind the processing to a particular encoder, or decoder, or bind an encoder/decoder pair. The encoder can customize the encoder output for decoder hardware related keys or data or identifiers or decoder processing. The decoder can likewise apply encoder specific binding using encoder specific keys, data, identifiers, or processing when processing data thus binding the decode process to an encoder.

Figure 11 shows a standards based processor (e.g. Standards Based Encoder 210) feeding a converter 213 referred to as a Standards Based Partial Decoder. Partial decoder 213 decodes a portion or all of the standards based encoder 210 output and then applies DFP processing to the standards based data in the dynamic processing on partial decode (or fully decoded) data 223 step. Optional additional processing is added in step 230 in the form of further processing (compressing) data output from dynamic processing (DFP) 223 and then output at output stage 240. Additional processing such as DSP 135 security can be added between stages 230 and 240 or at any other point in the processing. On the decoder a proprietary data format stream output 240 from device shown in Figure 1 1 can be decoded directly in the decoder. Or a software helper application can remove the Figure 11 DFP specific processing used to obfuscate the output data and feed the standards based decoder data to a standards based decoder once the DFP specific processing has been removed.

Decoder DFP removal processes used to convert DFP unique data to standards based decoder data can be performed in a software application or a hardware device or split between a software and hardware device.

This invention optionally includes sandbox technology that allows data (binary, script, table, other data) that indicates the correct processing steps necessary to

encode/decode the input data to be securely loaded into a secure memory, thus preventing the data loaded into the sandbox to be helpful to a hacker attempting to intercept DFP processed data. Any form of sandbox technology can be applied including Public/Private key encryption, symmetrical encryption, and other security techniques. DFP related data loaded into processors sandbox can be device specific and bound to device specific hardware secure keys, secure identifiers, unique code processing, or other unique device specific data. Code in sandbox can optionally be limited in what instructions can be executed or what memory addresses can be accessed preventing the sandbox code from performing malicious actions. Sandbox code can be optionally interpreted code with limited access to the client devices memory, hardware, or instruction execution. Sandbox code provides modification instructions or modification data for the modifications applied to the processing from data downloaded or read into the core processing code allowing for updated modification data to be dynamically read by the processor without recompiling new core processing code. Any of the processing performed that modifies data or instructions associated with a process will be referred to as modification data and can be generated or applied by CB/DFP or CASBuilder processing.

In many instances a chip must be manufactured without chip specific code or processing and the use of sandbox technology allows device specific DFP processing steps, instructions, stages, functions, or other data to be downloaded into a chip. In another example, DFP related processing is offloaded from a standard decoder to a second DFP chip using a secure exchange between the chip and the DFP chip. In this example, a non-secure non-DFP based decoder can have DFP processing performed by the DFP security chip.

DFP processing applies one or more processing steps at any core processing stage including but not limited to the following:

a. scrambling the final core processing output (or any other step in the core processing) with any form of scrambling algorithm, shift register sequence, data interleaving, encryption, transform, mapping, etc.

b. mapping the standards based data commands and format to a different data command or format, such that a standards based decoder and not properly decode received data,

c. interleaving or changing the data structure of the core logic output processing

d. buffering and interleaving segments of modified core logic output data. e. buffering, interleaving, and scrambling core logic output data.

f. processing of any kind applied to but not limited to transforming message data, formats, commands, headers, data structures, and any other data. Processing can be any form of data processing, mapping, transforming, encrypting, scrambling, and modification of the data or format of data or both.

In the above examples the term core logic output data would be MPEG H.264 output data for an H.264 encoder. For other data processing, core logic output data would be standards based output data. In the above examples the core logic output data is processed by DFP processing to modify data at any stage of the core logic processing including the input stage, core logic processing internal stages, and the output stages. DFP processing can be applied to any one or more of the core logic processing at any stage and even before or after core logic processing is performed. DFP processing modifies the standards based data format such that hackers will need to determine the DFP processing and apply DFP processing before they can display (or intercept) output data.

Figure 3 shows an example of the data values and associated control sequences for what will be referred to as a "standards" based video stream. In Figure 1 a Group Of Pictures (GOP code) is identified by the binary value 0x01, followed by a Frame Data header with binary value 0x02 a Frame Start header 0x03, a Frame Start Code 0x04, Pixel Data Start header 0x05 followed by pixel data. Standards based encoders and decoders will use these same values to process video and if the values are modified the standards based processing will not correctly identify and process the modified header and data values.

Using the inventive elements described herein (CryptoBuilder/DFP) to enhance an encode/decode process the data processing of encode and decode is modified from the standards based definition. Example are shown in Figures 4 and 5 using the same video input that produced the output shown in Figure 3. All of the message data and pixel data for the enhanced processing in Figure 4 and Figure 5 are modified from a standards based process making the data in Figure 4 unique to encoders and decoders that contain the processing code for this encoder. Likewise, the data and processing in Figure 5 is unique to encoders/decoders using the Figure 5 modifications. The processing modifications are generated using CryptoBuilder or the DFP processing with the same modifications made to the encoder (source) processing and decoder (receiver) processing.

Figure 6 adds the equivalent to cryptographic Initialization Vectors shown as IV 1, IV2, IV3 in Figure 6 to seed the scrambling or CryptoBuilder/DFP processing output for the data following the Initialization Vector (IV). IV s seed the processing such that the data for repetitive values such as GOP start codes or other

frame/message data will differ due to the contribution (scrambling or modification) generated by the IV value. IV s can be added anywhere in the data stream and can be a incrementing counter value, or a random value, or any other data. IVs should be unique for the file or data being processed but do not need to be unique between different instances of programs modified by CB/DFP processing techniques.

Figure 7 shows a simplified example of a process block or function or code section where input data (705 Input Bits) is processed by a processing block (710 Processing) and one or more output data paths is output (720 Output Bits path 1, 722 Output Bits path N). Figure 8 provides an example of where DFP/Cryptobuilder processing can be applied to the input bits and output processing. Dynamic Function Processing DFP (803) shown on input bits (805) and on multiple output paths (813, 815). One or more DFP processing blocks (803, 813, 815) is applied to any one or more of the processing elements for a device. DFP processing is paired such that appropriate DFP processing reverses the DFP processing applied by the data source. For example if a source adds DFP before outputting bits at stage 813 the data receiver will remove the bits on the receiver at stage 803. DFP processing can be applied to one or more processing blocks such as to the entropy decoder, inverse quantization, inverse transform, intra-prediction, motion compensation, frame store, deblocking filter of a decoder and the corresponding elements of an encoder. Likewise for other types of processing such as communications, control, etc.

While a single processing block 810 is shown, DFP can be added to one or more processing steps or blocks composing processing (710 or 810) applying DFP processing to processing blocks used to compose processing 710 or 810. For silicon logic DFP scrambling or transform or mapping tables or data can be securely downloaded into the chip. Secure download of DFP data is based on any secure processing such as Public/Private key PKI encryption or AES encrypted and downloaded into chip with the download process applying the appropriate decryption (for example, PKI with a unique private key per decrypting the DFP input data received by the chip). When added to silicon logic DFP scrambling or transform or mapping data is used to define the DFP processing applied by elements 803, 813, and 815 in Figure 8 and the silicon logic DFP data can be hardware or software data used to modify the hardware processing of the chip. It is envisioned by this invention that the DFP processing can be split with hardware DFP processing applied in one section of a chip or process and software processing in a second application of DFP processing, or hardware in the data source and all software in the receiver, or any mix thereof. CB/DFP processing coordinates the pairing of the data source (e.g. encoder) processing with the data receiver (e.g. decoder) regardless of whether CB/DFP processing was implemented in hardware or software in any of the devices

(source(s)/receiver(s)).

Figure 9 shows DFP/CB processing applied to a graphics process frame store processing used to build video bitmaps for rendering on display devices. Using a decoder as an example the decoder frame building process is shown in 910 connected to an optional address path DFP processor 913 and an optional data bit DFP process 917. Address path DFP 913 scrambles address values used to access memory scrambling the memory storage layout of a video frame in memory. Data path DFP processing 917 scrambles the data bits stored in memory.

Similar DFP processing hardware or software can be added to the graphic display buffer accessing hardware used to access the display frame buffer and render the frame buffer image on an output display such as a VGA display, or HDMI, or output composite or component video for display on an external monitor.

In Figure 9 and in any other example DFP optionally can have a random seed loaded at power-on or starting an application or at any other time such that DFP processing is unique based on each power-on or new instance of a decode process, or at any other event where the loading of a random seed is performed.

CB/DFP data of any type used to define the associated processing is securely loaded using any secure loading technique. One example is defined in the following steps:

1. Create DFP data (code, sequencer data, script data, binary data, or any other data).

2. Encrypt DFP data with Public key of chip that will receive DFP data.

(Optionally sign DFP data as well).

3. Transmit data to chip.

4. Chip receives DFP data, optionally verifies DFP data digital signature.

5. Chip decrypts DFP data into DFP storage.

6. During normal processing (not the download process) DFP processing uses DFP data for any processing including but not limited to DFP processing instructions, script data, data mapping, data transforming, and any other data processing.

Code, instructions, binary data, mapping data, script data or any other data used by the DFP processing is optionally securely loaded using any form of secure loader technology. In the above Figure DFP downloaded data is encrypted with the public key of the intended chip and the chip decrypts using the private key the encrypted data and loads the data into the storage area for the DFP. Any form of encryption (public/private key or symmetrical key encryption) can be used. Figure 12 shows an example where there is static code (1260 s-code) that interfaces to dynamic code (1210 d-code). Dynamic code is code that changes and is in one example, downloaded into a client device. Static code is code that changes less frequently than dynamic code. Dynamic code interface 1263 interfaces static code 1260 to dynamic code 1210. Dynamic code 1210 includes static code interface 1213 to interface dynamic code 1210 to static code 1260. An example of how dynamic and static code works is where the static code is used to download dynamic code containing a new and changing algorithm that changes frequently, for example every four hours. In Figure 12 static code 1260 includes a dynamic code downloader to download and verify the received dynamic code before executing dynamic code. Any form of code verification can be performed on the dynamic code such as digital code signing using Public/Private key cryptography or other techniques. Furthermore, dynamic code can be uniquely built for one version of static code using CB/DFP code building techniques. An example process flow for Figure 12 is as follows:

1. At power-on or when new dynamic code is needed - Static code (S-code) detects required version (from indicator in content or separate from content. (In some clients d-code is built-into s-code eliminating the need for d-code downloads and d-code only integrity checks)).

2. Static code downloads d-code into storage.

3. Static code verifies d-code code integrity and digital signatures (or other code integrity checking method).

4. If dynamic code integrity is correct static code (or another process) calls

dynamic code initialization interface function or another function.

5. Dynamic code initializes any variables, performs startup processing and

optionally integrity checks the S-code.

6. Dynamic code optionally adds the device hardware to make sure platform is secure and is the correct hardware.

7. If device hardware integrity check passes dynamic code is ready for operation performing whatever processing has been built into dynamic code.

In addition to the CB/DFP processing described herein there are other ways to create unique processing functions that will be described below. Any combination of the processing techniques (CB, DFP, MACROs, Code Chains, etc.) can be combined using any of the processing techniques described herein. For example, modified processing combining CB/DFP techniques plus code chains, plus MACROs, etc. is envisioned to build complicated processing blocks. While the various processing (CB/DFP, Code Chains, MACROs, etc.) are explained in different sections and using different figures they can be combined in any combination.

In this patent application the term Code Chain or CC is used to describe the structure or chaining of cryptographic processing steps defining the cryptographic processing for a client. Each code chain is sequence of programming steps, but unlike program functions, they are not called and do not return. Rather they execute from a programming language standpoint as large chains of in-line functions or instructions. The coding style for Code Chains is less procedural or less function in that the code executes as long runs of sequential code without a fixed point where they return. To allow the processing to stop at various points in the code chain an optional conditional return can be added based on a counter of how many code chains were executed.

One can think of a code chain as an group of Lego building blocks put together in a particular sequence. Code Chains are built of cryptographic logic steps and can be likened to individual Lego build blocks. A series of Lego building blocks are put together to form a Code Chain. Because the cryptographic logic steps are like Lego building blocks they can be arranged in various sequences in the same way Lego build blocks can be snapped together in different sequences. The in-line cryptographic building blocks can be randomly arranged to be unique for each client.

Code Chains are composed of Crypto Code called Crypto Primitives.

Crypto Primitives are in-line code pieces wherein a CP incorporates a cryptographic processing sequence or cryptographic function and other functions. However, optionally the return is conditional based on one of many different conditions such as a count, or a timer, or a stop address. Crypto Primitives can be likened to individual Lego Blocks.

The CP can include unused or harmless code that obfuscates the understanding of the code and creates somewhat random code signatures for each CP making

synchronization of old and new libraries using automated tools fail. In a modular of functional programming style the processing is typically broken up into small functions that are called by other functions. For example, the in following code example main( ) /* C programming functional style example */

call GetKeysQ; call AES(); call TripleDESO; call ShawlHash(); call Output Decrypted Data();

}

Instead of using a modular or functional processing design a code chain would include the sequential instructions without function calls are returns and the processing executes without returns before a large portion of the cryptographic processing is performed.

From a high level the execution of the above processing as performed by code chains would be as follows:

Main( ) /* Code Chain Style */

GetKeys code AES code TripleDES code Shawl Hash code Output Decrypted Data code

}

1. the entry point for the function main is loaded into a program counter or the function is called to get the chain started.

2. the source code for GetKeys executes without returning and after the GetKeys processing is complete the function does not return because there was no function call or function return added and the processing continues directly into the AES code. In the example code below the nomenclature GetKeys code represents the processing for the GetKeys logic in-line without any function calls or returns. GetKeys code will be a number of instructions for the programming logic without the calls and returns. GetKeys code is followed by the AES logic code without a function call or return.

3. The AES code executes followed immediately by the TripleDES code, once again without any function calling or returns.

4. After the TripleDES code executes the ShawlHash code executes (without call / returns)

5. After the ShawlHash code executes the Output Decrypted Data code executes outputting the data processed in the code chain.

As will be described later in this patent application, MACROs can be interspersed throughout the real processing to obfuscate the real code. In addition, a data morphing or mapping function optionally makes the memory data address map for clients different between clients.

Mix of CodeChains and functions

The above example provides an overview of one programming style of code chains, however there are other styles that are envisioned such as a mix of CodeChains and function calls where within a code chain there are function calls. Another envisioned style is where code blocks are executed and address points are used to indicate the processing logic using 'go to' type facilities of programming languages or processing. Yet another, is where CB/DFP processing is applied to CodeChains, functions, combined with other process such as MACROs.

Another example of CodeChains is shown below using what is called spaghetti style code techniques where the processing flow performs jumps to various processing sequences without a function or procedure structure. Spaghetti code is very difficult to reverse engineer because this coding style does not break processing into small code blocks.

Main( ) /* Code Chain Spaghetti Style */

{ goto GetKeys code main exit:

}

OtherCode: Other code pieces AES:

AES Code goto TripleDES code

OtherCode 1 :

Other codel pieces

Output Decrypted Data code:

Output Decrypted Data code goto main_exit GetKeys:

GetKeys code goto AES code

Shawl Hash :

Shawl Hash code goto Output Decrypted Data

Any Programming Language Supported

While the examples and descriptions have been modeled after the C or C++ programming language the techniques described herein are applicable to any programming language including assembly, java, Ruby, Perl, javascript, etc.

Random Entry Points

CodeChains optionally have no single entry or exit point for a code chain and as such the cryptographic processing can start anywhere within a code chain such as at the TripleDES or Shawl processing by jumping to the address of these functions. Since CodeChains are processing sequences containing dozens or even hundreds of cryptographic processing steps code or built in an in-line manner there can be multiple starting entry points for a single CodeChain. Each clients CAS (Conditional Access System or Digital Rights Management System) security library can have client unique processing by starting the processing of each CodeChain at different offsets within the CodeChain, or by conditionaly returning after a number of processing steps or by varying the processing flow using conditional branching..

Likewise, with conditional returns as described in other sections of this patent application the CodeChain processing can terminate after a number of cryptographic processing steps are executed.

Code Chains can optionally include real processing steps and bogus processing chains. A bogus processing chain is code that is not part of the real cryptographic processing for client but appears real forcing the hacker to spend more time in reverse engineering a client library.

In the example real Code or cryptopnmitives are designated rCP# or just r# and bogus Crypto or Code Primitives are designated bCP# or b#.

In a CAS library there are multiple Code Chains, and Code Chains can be entered and exited from at different points. Each Code Chain is composed of Crypto Primitives.

Code Chain 1 Example: rCPl, rC2, bCPl, b2, b3, b4, r3, b5, b6, r6, r7, b8, ... b50, r 17, b51, b52, b53,b54

A processing chain can start at a variable offset such as real function r5 or bogus bCP9 and process sequentially until b54 is executed or it can stop early after say 17 crypto primitives are executed using either a counter or a return address offset. What is interesting to not is that any combination of real and bogus crypto-primitives can be combined and when the chain executes a combination of real code processing functions and bogus code processing functions are executed in-line. In the above example the last 4 functions were bogus and as such the reverse engineering of the code chain will have to track back to determine the real and bogus functions. Since there will be a number of bogus functions, and in some cases they will outnumber the real functions there is a lot of bogus code to reverse engineer. Likewise, even with the real functions, they may only operate on a limited number of bits of the real keys or processing forcing the hacker to reverse engineer long code chains of real functions Cps operating on a few bits at a time and bogus functions.

Code chain is AES followed by 3xDES

MACRO_37

AES CODE

OPTIONAL MACRO 55

MACRO 88 3DES CODE

OPTIONAL MACR0 14

NEXT IN-LINE FUNCTIONS MACRO

NEXT IN-LINE FUNCTION CODE

NEXT OPTIONAL IN-LINE END OF FUNCTION OR IN-FUNCTION MACRO CODE

Note that MACROS may contain code that looks more real then the actual processing to send hackers on wild goose chases, or they may use real code but with different data address values for example.

Real AES uses what data

Camouflage AES uses what data

Real 3DES uses what data

Camouflage 3DES and other functions use bogus data values.

In the examples the term Macro will be used to indicate code that accesses and processes data but the data is not used in the real codes processing or if it is it is reversed back to be harmless. Macro code is camouflage code that makes reverse engineering more difficult.

One example of a code primitive is as follows:

CP1 :

1. Macro 1

2. Macro 2

3. four- rounds of in-line coded AES

4. Macro 3

5. two-rounds of in-line coded AES that looks like macro code 6. Macro 4...7

7. eight rounds of AES

8. Macro 8,9

9. twelve rounds of AES

10. Macro 10...15

11. six rounds of AES

12. Macros 16..23

13. Optional conditional return

14. Start of next cryptographic primitives

15. ... more cryptoprimates and camouflage code

128. goto step 9 /* This allows processing to loop from the last cryptoprimitive back into the processing such that cryptographic processing does not need to start at step 1 in this example. */

Conditional branches can be added to any of the processing (even MACRO code) to change the execution sequence of the code.

In the above example 32 rounds of AES were interspersed with 23 different Macros that also looks like AES processing but on harmless data. An optional conditional return based on some counter or other value is shown and the conditional return can end the execution of the code chain. For example, a counter in every 4^th macro can be used and when the counter hits 5 counting after the execution of 20 macros the return is executed otherwise the next code found in-line after the optional conditional return is executed.

Making Sequential Code

#ifndef MAKE_FU CTION_SEQUENTIAL void AES( void )

{ #endif

MacroN

AES code

MacroN+14

AES code

MacroN+23

MacroN+62

#ifndef MAKE_FU CTION_SEQUENTIAL void AES( void )

{

#endif

In the above example the AES function entry including setting the stack frame and the return normally added by a C or similar compiler is suppressed when the include variable MAKE_FUNCTION_SEQUENCTIAL is defined. When

MAKE_FU CTION_SEQUENCTIAL is defined then the AES function can be concatenated with other functions to make a code chain. Other ways to develop the code chain structure are anticipated.

Other code chain examples follow.

Code chain is AES followed by 3xDES

MACRO_37

AES CODE

OPTIONAL MACRO 55 MACRO_88

3DES CODE

OPTIONAL MACR0 14

NEXT IN-LINE FUNCTIONS MACRO

NEXT IN-LINE CRYPTOPRIMITIVE OR FUNCTION CODE

NEXT OPTIONAL IN-LINE END OF FUNCTION OR IN-FUNCTION MACRO CODE

In the above example the AES CODE is an in-line version of the AES algorithm and can include optional MACROS within the in-line code and not just at the beginning and end of a function.

Examples

Code Sequence

Client 1 :

Function Chain A in client: AES, 3DES, AES.16, HI, Tl, RC4, AES, BLOWFISH, RC4.8, 3DES.4, AES.24

Function Chain B in same client: AES.8, Blowfish.16, AES.8, H3, 3DES, Tl, RC4, AES, BLOWFISH, 3DES.4, T4, AES.12

Function Chain A and Chain B in the same client have different code encryption keys.

Key Processing for Chain A is started in one instance at AES.16 with a counter of 12, so after 12 sequential crypto functions are executed the Key Processing is complete and a return when counter == 0 is executed. In another instance or invocation of the Chain 1 processing the cryptoprimitive AES is the first function processed, while in another instance it is transform Tl. Server indicates to client an offset on where to start into the code chain, for example in code chain 1 the DRM starts with AES.16 and goes only to 3DES. A later invocation of the same code chain on the same client can start at a different address (e.g. HI) and go for a different number of processing steps completing the processing at RC4.8 for example.

The server coordinate the data processing of the cryptoprimitive processed data (finished data) with the output from the code chain being the reverse of what the server processing. Obviously the code chains cannot all process data to the same memory location or the memory location as this will be an easy attack vector for the hackers. Some of the code chain pieces perform bogus or camouflage processing to increase the difficulty of reverse engineering.

Macros - Code Signature Randomizer (Macro) to prevent automatic synchronization

Each code chain contains macro randomizers so that it defeat library synchronization tools such as saber bindiff and IdaPro. Randomization MACROS can look like real code segments or functions with read data that performs bogus processing forcing the hacker to reverse engineer much more code than if bogus processing steps were not included.

Code synchronization tools (version diff programs) such as Saber Bindiff or IdaPro can automatically synchronize different versions of binary code. These programs do this by creating a code signature or checksum on what the synchronization program processes program instruction binary data creating a function signature. The function signature might be the first 30 binary data values in what appears to be a program function entry point. The version diff programs for each function creates a signature in both the old and new versions of a binary image and attempts to synchronize the two images, that being finding common functions between the two and then highlighting changes. Because reverse engineering a binary code image is so tedious these version diff tools can save hackers weeks or months of reverse engineering work.

This invention includes the use of Macros or code scrambling techniques that change the function or code image binary signatures as generated by the code synchronization tools to prevent them from automatically synchronizing two library versions. There are many ways this can be done and one example will be shown using program macros. A program MACRO is a piece of code that does not perform any real processing and contains a variable number of instructions or has a variable length of binary data. The MACROs change the binary code image on a compilation basis or by using a processing function such as a Macro swapper.

Macros optionally change on each compile - or even each download since they are ignored code. A macro swapping or randomization processing performs automatic macro definition swapping or macro code randomization wherein after randomization or macro swapping each crypto primative has a new code signature and the DRM chains cannot be synchronized with prior versions .

Macro randomizers work on functions and code chains

CodeChainlQ

{

/* AES( ) - in line version of AES code cryptoprimitive */

MACRO_37

First Part of AES CODE

OPTIONAL MACR0 55

Final part of AES Code

OPTIONAL MARCO_73 if CP Lenth <=0 return;

/* Other in-line functions */ /* Triple DES( ) cryptoprimitive - in line version of 3DES code*/ MACR0 41

First Part of TDES CODE OPTIONAL MACR0 8 Final part of TDES CODE OPTIONAL MARC0 76 if CP Lenth <=0 return; }

In the above code for one compilation MACRO_37 consists of 28 binary instructions that appear to fix a stack frame and then perform a summation on data. However, the code contained in the Macro is camouflage or bogus code and the results are stored in a non-used memory location and never used in real calculations but only used in camouflage processing by other macros.

When a new version of the code is built MACRO_37 will consist of 44 binary instructions that appear very different from the 28 binary instructions of the prior compilation. In this example the 44 binary instructions access memory and perform exclusive OR functions on the memory. The code signature for the AES

cryptoprimitive with MACRO_37 will appear very different between the library versions and the code synchronization tool will not be able to automatically synchronize the two library builds. Additionally, since the version diff tools look for function entry points and the code in the libraries is mainly in-line code the version diff tools will not be able to synchronize the two versions. Furthermore, the

MACRO'S can have bogus code or camouflage code that looks like real

cryptoprimitive code making it difficult to synchronize the two library versions.

There are many different ways that the binary code signatures for a function can be modified and only one example was provided above. Other processing can rearrange the MACROs or MACRO code to create new binary code versions that cannot be synchronized by the automatic synchronization tools.

In addition, the library (e.g. Security core containing cryptoprimitives ) code can be automatically shuffled on a frequent basis creating security core binary images that change on a frequent basis without rewntting the library code. And, because in some examples, the camouflage or MACRO code looks like real cryptographic processing determining the real code from the camouflage code increases the difficulty in reverse engineering a code library.

In the above example each crypto function has a Macro at the start of the function, optionally one or more macros in the body of the AES CODE and then an optional Macro at the end of the function.

The purpose of the macros are to randomize the AES code so that the function cannot be traced back to a prior library version.

The actual code added to the cryptoprimitives will change on a compilation or other basis such that each compilation of the code produces different code signatures.

MACROs can also be concatenated together and changed between library versions. For example the first release version of a client security library built using the techniques described herein can have the following code chain:

MACRO_71

MACRO_4

MACR0 19

AES_IN_LINE_CODE

MACR0 9

3 DES_rN_LINE_CODE_4_ROU DS

MACRO 21 and the second release version of the library the following:

MACRO_33

SHA_1_HASH

MACRO_8

MACROJ03

MACRO_70

3 DES_IN_LINE_CODE_ 16_ROU DS MACR0 91

AES_IN_LINE_CODE_ 12_ROU DS MACR0 62

In the above example the code is shown as being concatenated into a single code piece, however, other software programming techniques can be applied such as using #defines around the function.

No fixed entry exit points

The sequence of cryptoprimates can have variable entry points with entry point data provided by the server or based on some other data (counter, offset data, hardware values, etc.). For example, in the above example the actual first real processing step can occur after MACRO_70 with the 3DES_rN_LINE_CODE_16_ROUNDS code and server supplied data or other data is used to indicate the starting point in a code chain.

Code chains can also include conditional and non-conditional branching to make the processing flow through the library non-sequential. Conditional branching optionally uses server side data or other data to change the processing flow through a cryptographic chain. Conditional Execution

Optional data from any source (server or client) is used to change the processing based on conditional execution and testing the data. In one example, a counter is used and counted down and when the counter value reaches zero an a conditional test on the counter is performed the code chain processing is completed.

Data Maps for Unique Data Layouts per Client

Another element of this invention is including an optional data mapping process wherein the in-memory data map or data addresses for the data used by the processing chains is also unique. This increases the difficulty of hacking because each clients data map (the addresses of where data is stored) can be modified on a client-by-client basis, or even a transaction-by-transaction basis.

Each real or bogus crypto primitive can optionally have a data mapper associated with it. The data mapper is used to indicate the memory locations of where the crypto primitives store there data. Thus, each client can have client unique processing as well as client unique data memory layouts.

The data mapper can be used to indicate where variables for the different Cps are stored. Data mapper can be an optional table used when reading / writing CP data by the CP functions.

The CAS library is composed of dozens or hundreds of Cps arranged in multiple code chains. Each code chain optionally has its own encryption key for the code so that reverse engineering of the code chain cannot occur until the code chain is activated.

XOR_l( in, out) /* without data mapping */

{ in xor key;

}

XOR_l_DataMap( in, out ) /* with data mapping */ {

&out[datamap4] = in xor key[ datamap5];

}

In the above example the datamap[] array can be used to obfuscate the memory layout.

Data morphing

An optional data morphing process that morphs thread data such as malloc( required size + random(64)) Adds up to 64 bytes to the block size to randomize the layout of memory. The optional data morphing process can be added such that the data block size of malloced data and the data offsets within the malloc'd data memory can be unique or modified on a per client or other basis. In addition to the malloc example other forms of data morphing or changing the memory address of data values can be used.

One example is where the actual size of the data requested by malloc varies by a random amount of bytes. One way to have this work is to add a random data size to each malloc call such as the following malloc(32 + random(64). In this ex example each malloc call will allocate a 32 byte array with additional memory bytes so that data memory usage and tracking is made more difficult .

There are many different ways to perform the datamapping or data morphing process. Another way is to use static variable names and rearrange the static variable memory layout before code compilation. The static memory layout can also include bogus data variables that obfuscate the memory layout.

Other forms of data and code obfuscation are supported including adding Cloakware or other code and data obfuscation techniques can be added to increase the obscurity of the security library.

This optional data morphing or data transforming modifies the memory data address for real data and camouflage data so that the data address are not static and can differ between client or even between transactions with the same client. Optional data morphing can be applied to both real processing steps and associated data memory and camouflage processing steps and associated memory.

Other Obfuscation

Additionally, Cloakware or other software obfuscation tools can be used after the cryptochains are built along with the build unique Macros to provide additional obfuscation to the client security library. It is envisioned that after the crypto library source code is processed and scrambled that cloakware or other obfusction tools can optionally be applied to the library and then the library is complied and unit tested using hundreds of millions of test-vectors. Upon testing of the obfuscated and compiled and tested library the library can be released for use by client devices.

Static Code Analysis Prevention - Encrypted Code Chains

It is envisioned in one version of the client library that multiple code chains are included in the client library and that each code chain includes code encrypted using different code decryption keys. The code decryption key is used to encrypt the binary data so that a client library cannot be statically analyzed after a simple capture of the binary image. When multiple code chains are included in the library and code chains use different code chain decryption keys then the code chains that have a different code decryption key then the currently active library cannot be debugged or analyzed until the server sends the corresponding code decryption key. The table below shows and example where the client library has a number of cryptographic code chains and the associated code encryption key.

When the client security library is first delivered one of the code chains will be used after the correct code chain code decryption key is provided. The code chain decryption key is used to decrypt the code and static data associated with code chain in the library, and the library code cannot be run (or analyzed) until the server delivers the appropriate code chain decryption key.

Randomized OTP CAS loader - where Encrypted CAS Code Chains are scrambled during unpacking

The binary code segments that make up the client library can optionally be scrambled in different ways on the server side before downloading the library or on the client side before programming the library into flash or before running.

The following provides a code scrambling example:

Client code as built after compilation: rCPl, rC2, bCPl, b2, b3, b4, r3, b5, b6, r6, r7, b8, ... b50, r 17, b51, b52, b53,b54

Client l's run time code image: b4, rCP8, bl7, b6, b53, rCP2, b9, R3, ...

Client 2's run time code image: b7,b7, b53, r4, bl, bl9, r 1, b50 ...

Client 3's run time code image: b54, r7, bl2, b3, bl, b44, r3, r2, bl 1, b6, b9, ...

Scrambling can be performed before delivering the code to the client or after the code is delivered to the client. The server will coordinate server side processing to encrypt data using the right processing steps so that the client library can properly decrypt data.

Dynamic Key Processing for each client where client keys are unique Client Unique encryption/decryption

The chain of cryptographic processing can be made client unique using the techniques described herein. The above examples show three clients each with unique cryptochains or cryptographic processing. Groups of clients, or each client in a system can have client unique code images and client unique cryptographic processing.

In one embodiment of the invention an automated processing tool is created to automatically build unique cryptochains or to arrange cryptoprimitives in various ways. This automatic tool allows a security company to build new security clients or create new DRM or CAS processing steps without programmers. The automatic security builder program can build hundreds or even millions of unique versions of the security client wherein the cryptographic processing and client libraries are unique. As will be described later the automatic code builder that builds cryptochains containing cryptographic primitives can be based on a replaceable crypto core architecture where there is a static security core that downloads and verifies the code integrity of replaceable crypto cores. The replaceable crypto cores can change frequently without needing to change the static security core or other parts of the system middleware and client software.

The automated client library tool will be called CAS Builder and uses similar processing to CB/DFP described herein and will chain together dozens or even hundreds of cryptographic processing steps or cryptographic primitives in different ways creating unique client libraries. Since each cryptographic primitive has been tested and is reversible chaining together cryptographic primitives in different ways will not create sequences that fail to encrypt and decrypt or process correctly.

Camouflage code processing steps are optionally mixed into the client libraries to camouflage processing. For example the library can contain 10% of the processing that is real and is required for producing the correct processing results while the other 90% is camouflage but looks real, making code tracing of real processing difficult.

Server can optionally scramble in-line code pieces when delivering client library code. Server has a collection of CHATNABLE CODE PIECES that are optionally scrambled and put together when delivered to a client providing client unique code threads and server keeps a code thread list to know how to deliver keys to the client. Any of the processing and optional scrambling can be made unique (unique code, unique keys, and combinations) for each device or client or a group of devices or clients.

Replaceable Crypto Core

Another optional element of this invention is the support where crypto-library interfaces exposed to other system software such as system middleware does not change and calls are made to an static interface that does not change. However, while the static cryptographic library interface to external system software such as middleware does not change an internal replaceable Crypto Core is included in the security library. The replaceable Crypto Core is a portion of the security library and the replacement or update of the Crypto Core is done in such a way that the middleware system interfaces do not change. This allows the security processing portions of the security library to change without need to change middleware interfaces. Crypto Interfacing in Middleware does not change and new downloadable Crypto Cores can be delivered without changing Middleware Crypto Interface on a frequent basis. The replaceable crypto core has static middleware APIs and depending upon the code signing architecture of the client device the replaceable crypto core may reside outside the area that is checked by code signing in the client such that static code signing values remain the same even after the crypto core is replaced. The partitioning is shown in the Figure 13. In Figure 13 a middleware software image 610 interfaces to the security library 600 via static crypto core APIs 620. static crypto core APIs 620 are used to initialize the security library 600 and pass data between the middleware 610 or other system component or software interfacing with security library 600 and the security library 600. A static security core 633 includes the static crypto core APIs 620 and additional static crypto core core 620. The software in the static security core 633 does not change and optionally has a digital code signature that also is static and is often part of the client software image including middleware software code image and other client code (Operating System, Network stack, Client Application Code, etc.) and an optional code digital signature on all these software pieces. If the replaceable crypto core code was included in the system code digital signature calculations then when the replaceable crypto core code changed the digital signature check would fail, or a new digital code signature would need to be computed and reflashed into the client device. This is impractical because it means all of the software pieces would need to be completely retested and this is something that is not desirable.

The replaceable crypto core code section is not included in the clients digital code signature check but rather is verified via a second digital code signature on only the replaceable crypto core. The code for this second digital code check is stored in the static security core 633 and does not change and the purpose of the code is to verify the integrity of replaceable crypto core 640/641 or other versions by verifying the integrity of the replaceable crypto core and its corresponding digitally signed hash value.

Static crypto core code 630 has interfaces to the Replaceable Crypto Core (640 for version A and 641 for version B of the replaceable crypto core) that also do not change and interface the static crypto core code 630 to the replaceable crypto core 640. The purpose of the replaceable crypto core 640 and subsequent versions is to create security moving targets wherein the security code changes based on changing the replaceable crypto core 640 without having to replaceable the static security core 633. In fact the replaceable crypto core 640 does not need to be stored in flash (or non-volatile memory) and can be downloaded to RAM memory upon power up.\

The static security core 633 includes code to verify the integrity of the downloaded replaceable crypto core 640 and all subsequent versions. Any form of digital code signature generation and checking can be applied to the replaceable cryptocore and when supported by the hardware the signatures are verified using a value stored in permanent non-alterable storage in a hardware chip.

Control Word Obfuscation

In security systems there are keys or cryptographic data that if compromised create system hacks that are easily spread system wide. One such attack in the pay television security area is control word sharing. Control words are the encryption keys used to encrypt and decrypt video. This invention provides added protection against control word sharing piracy when compared to legacy systems because the code that computes (decrypts) the control words can be placed in the replaceable crypto core as shown in Figure 14 and can be updated on a daily or weekly basis. This will force the hackers to have a full-time person or team of people working on reverse engineering each new library to see how control words are written and then to capture the control words and export the captured control words to hacker control word sharing sites. Code word decryption and outputting to the control word register in a chip, or even doing all of the video decryption in software so control words are not available at a control word register address is performed in multiple code primitives forcing the hacker to have to reverse engineer hundreds of cryptoprimitives that change on a frequent basis. In addition, software encryption can be based on one of a million different encryption algorithms built using the CB/DFP/CAS builder techniques wherein each encryption algorithm is different than the other algorithms.

Control word decryption is performed in dynamic section of code that changes on a frequent basis. A portion of the video is software encrypted without using control words or in addition to control word key encryption. Software encryption is based on modified standards based algorithms preventing the use of a standards based algorithm (and associated key) from decrypting the software encrypted data.

CW Sharing prevention methods a. Dynamic CAS client writes Cws in different ways and the way the CAS client writes the Cws changes on a frequent basis and the way the CW is written is not obvious. The frequent basis is based on server data that modifies the processing path through the crypto core, or updated crypto cores. b. CW register address computing method changes such that hacker boxes and other hackers software must adapt quickly. c. Software detects hacker boxes and corrupts data making video decryption continue but with the wrong keys thus forcing the hacker to remove code that detected hackers hardware. d. Over-the-air updates of the replacable cryptocore allows new s/w protected CW outputting to occur, or updated decryption algorithms on encrypted video encrypted using modified standards based encryption.

The processing steps and protections described herein can optionally be applied to the automatic code builder

• where in changes are made to the CW processing and address computation to make it hard to find where Cws are written

• or CW processing and video decryption is performed entirely in software

• on a frequent basis ECMs processing algorithms are changed

• data memory address are changed frequently or unique per client

Fast changing code is optionally run code out of RAM memory downloaded over the air so that code does not need to be flashed. Upon power-on STB receives RAM crypto core over the air and RAM crypto core changes frequently.

Many SOCs include hardware decryption to offload content decryption from the software. This invention includes combined hardware and software decryption to prevent control word sharing. In normal content encryption systems the content is encrypted with a single encryption algorithm such as AES or CSA. One element of this invention uses two encryption algorithms wherein one of the algorithms is decrypted in software and the second algorithm is decrypted in hardware. Figure 14 provides an example of the dual encryption. In Figure 14 AES 710 section is video encrypted using DVB style AES encryption with control words. SW 720 shows video encrypted by software using a different algorithm than AES. SW 720 can use dynamically changing algorithms based on modified versions of industrial strength algorithms such as AES. Hundreds or even millions of modified versions of AES encryption/decryption processing is output from CB/DFP/CAS builder processing. Hackers cannot simply access a key to hack the system. In one example, the modified AES algorithm does not use a key and the security is in the changing (modified AES) encryption/decryption algorithm and not using a key. In another example, modified AES algorithm includes a encryption/decryption key. Software decryption provides for protection from control word sharing by eliminating piracy from simply stealing control words. Hardware decryption using the second encryption method reduces the added processing load of software decryption on the client device.

Within the content stream an indicator is used to signal which encryption algorithm was used. On the head end or content delivery system side the two (or more) different encryption algorithms are used to encrypt the content. The content is encrypted using the two different algorithms and will be referred to as algorithms A and B. Algorithm A and B can be any type of encryption algorithm and are preferably different algorithms. For example, algorithm A is CSA encryption and algorithm B is a modified version of AES.

Combined software and hardware decryption (CSHD) can operate with existing unmodified headend equipment by applying CSHD encryption before encryption by the headend equipment and in a manner where CSHD encryption signaling is done on a video stream or audio stream or datastream event basis (collectively referred to as Stream Events) and not using standard MPEG2-TS (or equivalent) transmission scrambling control TSC bits). Existing unmodified headend equipment will modify MPEG2-TS TSC bits such that the CSHD software in the client cannot use the MPEG2-TS TSC bits to identify which packets had CSHD encryption. Stream Events will indicate to the CSHD decryption client which packets were encrypted without any packet signaling. Many different conditions and Stream Events can be used by the CSHD Encryption and Decryption process to perform CSHD encryption in addition to normal headend equipment video encryption. In one embodiment CSHD encryption is applied using an non-standard encryption algorithm that is not supported in the video transport stream data path decryption hardware. In another example, standards based encryption sets TSC bits to 1,0 and 1,1 per the MPEG 2 and the software encryption indicates SW encrypted data packets by setting the TSC bits to 0,1 (unused by MPEG). SW encryption algorithm can encrypt such that the prior TSC bits indicating odd or even key usage can be inferred from the video stream by never SW encrypting (and changing the TSC bits) after the encryption switches odd/even key bits (TSC=1,0 switching to 1,1 or TSC = 1,1 switching to 0,1). When SW encryption does not encrypt the packet where a key change (TSC bits change) occurred than the decryption process can restore the TSC bits to the value of TSC bits of the prior non- SW encrypted packet and providing the correct TSC bits for the HW decryption process.

The software encryption/decryption algorithms, or keys, or both of the CSHD can change on a frequent or transaction basis forcing hackers to have to constantly update their piracy software.

CSHD can use different keys from the normal video encryption stream key ladder forcing hackers to have to pirate two separate key ladders to perform a successful attack on a system.

Another optional element of this invention is the use of separate key ladders for the software decryption and hardware decryption making common (between software and hardware decryption more difficult). The separate key ladders can optionally use separate encryption algorithms for the different keys in the key ladder.

Software over-encrypt

In systems where it is impossible to coordinate the application of two coordinated encryption algorithms such as algorithms A and B, it is also possible to over encrypt data with a second encryption algorithm. For example, encryption A is applied by a content encryptor such as a simulcrypt enabled cable MUX that will be referred to as MUX. The MUX encrypts using only encryption algorithm A. Content encrypted with algorithm A is then over encrypted with algorithm B and unless algorithm B is applied to the algorithm A encrypted content the decrypted content using only algorithm B will not be correct. Any order of applying algorithms A and B can be used as long as the decryption is applied in a manner where the original clear content is output after decryption by all the algorithms used (e.g. A and B).

In one example of software over-encrypt, even though the Cws are the same between the hackers control word sharing site and the STB the over-encrypted stream must be decrypted before the over-the-air stream can be used. As such, decrypted portions of the encrypted content data or content stream must be sent from the hacker control word sharing site and this can present numerous problems in terms of the required bandwidth to transmit all the video. In addition, one or both of the encryption algorithms can optionally change forcing the hackers to have to reverse engineer the algorithm that changed.

Signaling the over-encrypt region

In some cases it is not possible to modify system signaling for multiple algorithms and in this case over-encryption or CSHD encryption is performed after certain stream events such as using algorithm B on the first 10 packets after the start of a I-Frame, or after a B or P frame in MPEG video or after the first 20 packets of the start of a video segment, or audio segment or any other event. In fact, the signal-less encryption where CSHD encryption is implied by stream events and not explicit data bits or signaling can vary on a per-title or per-transaction basis. Either algorithm can be applied during the event period and after the event period the other algorithm is applied. In situations where one algorithm has better security properties it is preferable to encrypt content using a higher percentage of the stronger algorithm than the weaker algorithm. For example, AES is stronger than a traitor tracing algorithm encryption and AES is applied in one example for 80% of the content encryption and encrypting 20% of the content with the traitor tracking algorithm.

Dual strength ECM/EMMs

This invention also includes two different encryption processing algorithms on content encryption keys with each one of the different algorithms providing different properties. ECMA is encrypted using algorithm A and ECMB is encrypted in a different manner using a different algorithm with different properties than algorithm A. In one example, ECMA is used to provide 128 bit AES or stronger security and ECMB is used with a different algorithm that may not be as peer reviewed as ECMA's algorithm but has a desirable feature such as the capability to track traitors (pirates) based on the ECMB values they are publishing. There are many algorithms where a client bases can have key values that are unique for a client but result in common decryption for a video stream encrypted and broadcasted to a large population. The dual strength element of this invention results in providing security for common keys delivered to all subscribers and traitor tracing or other properties for keys that may not be as strong as the encryption algorithm using common keys but provides the capability to detect traitors from algorithm and key properties.

ECMA or ECMB or both can be modified encryption/decryption algorithms output by CB/DFP/CAS Builder processing. ECM (ECMA and ECMB) processing can also be split between two different pieces of hardware such as a secure microprocessor in addition to the ECM processing performed by the main System On a Chip (SOC) used in the manufacturing of Set Top Boxes.

Virtual Machine and Hardware Emulation Detection

Crypto primitives optionally include code to detect virtual machines or hardware emulators or debuggers. One such primitive can detect a debugger or vitual machine or a hardware emulation or software simulator or other software or hardware tool and then corrupts the cryptographic processing at a later point in the processing chain such that the processing chain incorrectly decrypts data or performs incorrect processing. There are many ways the code can detect virtual machines or hardware emulation or software emulation including the items discussed in the hardware binding section or code to check for hardware or device specific processing or timing or other real (not virtual processing) including but not limited to Direct Memory Access controllers, timing on Multiplication hardware or other real chip specific processing, accessing any h/w registers accessible only in the dream box or only in the real hardware, timing instructions such as push, pop, memory read, block memory access and other instructions. VM and hardware emulation detection code can be modified by CB processing such that different versions of detection are used in the different versions of the dynamic code forcing hackers to continuously re-hack the code to defeat the different versions of emulation detection.

In one embodiment when it is determined that inappropriate hardware or a modified environment exists then data values in memory can be set and used by later cryptographic processing to corrupt processing such that the processing doesn't stop, but the decryption is not correct. It is better to generate bad data somewhere in a long processing chain than to stop because the processing flow looks real and the hacker must find wherein the processing the data was corrupted. Register/Control Word Write Obfuscation

A common hacker attack vector is control word sharing in DVB or equivalent systems. In this invention the address for the control word register is not hard coded via a define or stored in the code in an obvious manner. Rather it is computed during the CP processing and preferably output before the end or return of the cryptographic chain making it difficult to detect. For example, a certain chip has a Control Word register address of 0xF0000040 and this is the register where the Control Word (video unscrambling or decryption key) is written to with the correct key to unscramble or decrypt video in DVB systems.

In many software designs a memory address register or I/O register will be loaded with the value 0xF0000040 (hex) and then the decryption key for the video stream will be loaded by performing a memory write. In this invention the loading of the address 0xF0000040 will be performed using different non obvious values in memory such as adding 4 memory stored values that when added sum to 0xF0000040, or by exclusive OR-ing different memory locations to generate the correct address. There are a number of different ways this can be achieved. The purpose of this obfuscation is to make finding the actual location where a fixed memory address such as the Control Word register is written to when writing the video descrambling key is located difficult.

Any of the cryptographic primitives, cryptographic chains, or register/control word write obfuscation code can be stored in the non-volatile memory such as flash memory, or downloaded dynamically when the CAS client starts operation after power on. Dynamically downloaded allows for the code to change without having to write the code to flash memory. Dynamically downloaded also means that the hackers must capture code images from the download before they can begin their debugging. It is envisioned that portions of the CAS client will be in flash memory and portions will be downloaded, or the entire CAS client will be stored in flash, or entirely dynamically downloaded.

It is also envisioned that CCs or CB/DFP output code can be downloadable on a frequent basis (hourly, weekly, monthly, quarterly, or annual basis). Software downloading allows frequent changes to the CCs and creates a moving target that can frustrate reverse engineering efforts. And, because the CCs include static analysis prevention MACROs or programming techniques, the hackers cannot uses binary code synchronization tools such as Saber BinDiff to quickly synchronize their prior hacking work with the update CCs.

Digital code signatures can be added to the Ccs to verify the Ccs have not be tamperd with and are authtentic preventing hackers from ingecting Ccs containing hacker modified code.

Multiple Code Chains in a CAS Library

In a client CAS library there can be a number of code chains with each code chain representing what can be considered one version of the client CAS or DRM processing. The incorporation of a number of code chains in a single library allows the CAS processing to change to a different chain without downloading new software to the client. When multiple code chains are included in a CAS library each unique code chain can be encrypted using a unique encryption key (CodeChain Encryption Key). When the CAS library is first deployed one of the multiple Code Chains is used for a period of time and the other Ccs in the library are dormant until the server indicates that one of the other Ccs should be activated. When a different CC is activated the server will also send a CC decryption key allowing the library to be decrypted and loaded into memory for execution by the CPU running the CAS client. The use of a Code Chain Encryption / Decryption key allows the various Ccs to be protected from reverse engineering until the server activates the encrypted CC. The server does not send the client the CC decryption key until that version of the CC is activated. Hackers will only have access to encrypted binary data without the decryption key being in the client library and as stated above, the decryption key is only sent when the library is activated. It is envisioned that one CC will run for a long period of time until it is suspected there is hacker activity and then when the hackers are getting close to completing a hack a new CC will be activated.

Client unique DRM

The cryptochains or cryptoprimitives or any of the other processing steps described herein can be optionally unique on a per client basis. Key data or Digital Rights Management DRM data procesing can be unique on a per client basis wherein each clients cryptochain processing is different either because the cryptochains are unique or the conditional branch data or starting points and end points for a cryptochain is unique. As discussed in other sections CCs and other elements described herein can be combined with any other CB/DFP CAS builder processing.

Data of any kind (DRM, key or any other data) can be processed in client unique ways as described in other parts of this patent application and can include hardware binding as described in other parts of this patent application. In addition client DRM or security processing can be unique on a per transaction basis by modifying the conditional branch data or starting point or end points for a cryptochain or by downloading new cryptochains or cryptoprimitives to the client device on a per transaction basis or other basis.

Client Binding

An optional element of this invention is the binding of a client to client hardware. Client hardware binding is the process of associating hardware and client specific features and functions with cryptographic processing wherein hardware specific data, register values, timing, and other features and functions are used as input data or keys for cryptographic processing. Examples of client hardware specific data and features include but are not limited to the following: client identification value, client serial number, client MAC (Media Access Controller) address, chip Ids for silicon chips used to build the client, register values that may be unique to a chip used in the client, Flash memory or EPROM or ROM data values, cryptographic keys stored in chips or secure memory, interface registers, smart card or secure microprocessor data or values or keys, and other data.

Client binding processing steps seek to verify the correct hardware or Ids or data is found to verify the hardware is correct and has the correct Ids. It is envisioned in this patent application that many of the cryptoprimitives in a cryptochain will input or output or check for correct hardware Ids, keys, hardware functions, etc. to verify the hardware is correct and not a clone or emulator. Another option is to use hardware specific ID values or key values in the processing steps of a cryptoprimitive to verify correct hardware with correct data values. Another option is where the server side processing knows hardware specific data values such as register settings, serial numbers, chip Ids, etc. and uses these in its server side processing when processing data for a client. Preferably unique client data is used such that only a client device or STB containing the correct or corresponding data can properly decode the server processed data. Likewise the client can use server specific data or client specific data when preparing data to be sent to the server.

A simple example of client binding is as follows:

In one of the code primitives a chip register value is read that is static for this client device. The chip register value is used as a part of the key used to encrypt a block of data for the server. Other keys can also be used to encrypt the data and the server will use data corresponding to the expected client data used in the cryptographic processing along with other keys or data as well.

Key hierarchies

In many applications security processing incorporates key hierarchies for different management processing and the inventive steps described in this patent application can be applied to any key level or key processing or security processing including client security systems with key hierarchies.

Figure 15 shows a partial segment of content with clear (unencrypted) content 1510 followed by an encryption key 1520 that is used to decrypt encrypted content 1530, followed by other data 1540 containing more encrypted content (encrypted using key 1520 or another key (not shown)) and other non-encrypted data. In one example for Figure 15 encryption/decryption key 1520 is stored unencrypted in the clear such that anyone can identify encryption key 1520 and use the key 1520 to decrypt encrypted data 1530. Storing key 1520 in the clear (unencrypted) used to decrypt encrypted data 1530 does not provide strong protection of encryption key 1520. In another example, encryption key 1520 is encrypted with a known data value such as 0x5a5a or 0x0000 or other unencrypted data (not shown in the data stream). Figure 15 provides for the storage of encrypted data 1530 along with an easy to access decryption key 1520 that is not encrypted or may be encrypted using an easy to access key either in the content stream or a known static (does not change) key based on some static data. For example, if 1520 Encryption key is in fact encrypted than the key used to encrypt encryption key 1520 can be a static value (always 0x0000, or some other value) or is contained in the clear in the content making it easily accessible. In Figure 15 any form of identifier can be used to identify clear content 1510, encryption key 1520, encrypted data 1530, and other data 1540 including but not limited to other encrypted data using encryption key 1520 or another key (not shown), or other content data.

Claims

Claims I claim:

1. A method to obfuscate processing associated with a process wherein

processing data used to implement a data source process is identified;

identified data source processing data is modified with data source modification data; data source processing with modification data is build using software tools associated with preparing data source process; data receiver processing code segment location is identified where reverse modification data must be applied to reverse the data source processing data modifications; data receiver modification data removing data source data modification is applied to data receiver processing; modified data receiver is build using software tools associated with preparing data receiver process; and the modified data source process and modified data receiver processing are deployed together such that the modification made on the data source processing is reversed by the modifications made to the data receiver processing.

2. The method of claim 1 wherein a version ID is associated with both the

modified data source processing and modified data receiver processing.

3. Claim 1 wherein modification data includes using random data;

4. Claim 1 wherein modification data includes changes to the processing code;

5. Claim 1 including unmodified data source and unmodified data receiving processing in addition to modified data source and modified data receiver processing.

6. Claim 1 wherein a plurality of modified data source processing and data

receiver processing versions are deployed to data source processing hardware and data receiver processing hardware.

7. Claim 6 wherein one of the versions of modified data source processing and data receiving processing versions is replaced by another version on a periodic basis.

8. Claim 1 wherein modification data is read from modification data source.

9. A method to encrypt data in a content stream wherein the encryption key used to encrypt data includes an identifier and is encryption key is stored unencrypted in the content stream.

10. A method to protect content wherein a portion of the content is encrypted using a first encryption algorithm; a portion of the content is encrypted using a second encryption algorithm; wherein one of the two encryption algorithms must be decrypted using software in the decrypting device.

11. Claim 10 wherein the encryption algorithm that must be decrypted using software changes on a periodic basis.

Abstract

An automated tool builds a plurality of uniquely paired data source and data receiver programs by identifying and modifying data or program instructions on the data source processing and identifying and applying reversing modifications on the data receiver such that the uniquely paired data apply and remove the same process modifications. In one example a paired data source and data receiver program is periodically replaced by another paired data source and data receiver program having different modifications than the pair being replace. In another example, modification data to a program or process is loaded after the program is process is built allowing for dynamic updates to the data modifying the process data or instructions or both.