Apparatus and method for authenticating transmitting applications in an interactive TV system5625693Abstract An executable interactive program is combined with audio/video data for transmission. The program is divided into modules, similar to computer files, and a Directory Module is created which links program modules. Security for the executable application is provided by attaching a signed certificate to respective Directory Modules. The integrity of respective modules is monitored by hashing respective modules and including respective hash values in the Directory Module. A hash value of the Directory Module containing the other hash values is generated, encrypted and attached to the Directory Module. At a receiver the certificate is decoded and checked for authenticity of provider. If the certificate is authentic the program may be executed but only if receiver generated hash values of respective program modules are identical to corresponding hash values contained in the Directory Module. Claims What is claimed is: Description This invention relates to a method and apparatus for insuring that data accepted by an interactive television system is authorized data.
______________________________________
1. compute
A = S.sup.2
2. compute
B = Q1 times N
3. compare
A > B; If A< B quit, signature cannot check,
else if A> B
4. compute
C = A- B
5. compare
C < N; If C > N quit, signature cannot check,
else if C < N
6. compute
E = C times S
7. compute
F = Q2 times N
8. Compare
E > F, If E < F quit, signature cannot check,
else if E > F
9. compute
G = E - F
10. Compare
G = D, if not, signature does not check.
______________________________________
Note that all arithmetic operations are simple multiplications or subtractions. The detection of an erroneous signature may occur at steps 3, 5, 8 or 10. If an erroneous signature is detected at steps 3 or 5, very little computational time has been expended. The AVI receivers are provided with the public keys (and desirably helping quotients Q1 and Q2) of the respective system providers for decrypting signed certificates included with PC-data to determine program authenticity. If program authenticity is not confirmed, the received application is immediately dumped from the receiver. Central to such a security system is the assignment of unique identifiers, ID's, to application providers and the system controller or server. The system controller allocates unique e.g. 32-bit ID's to each trusted AVI application provider and also issues a certificate for the application provider's public key. The certificate is essentially the system controller's digital signature on the application provider's public key and includes fields such as the expiration date of the certificate, the ID of the provider, and a limit on the amount of storage an application with this ID can use in the file system of the receivers. The system controller may employ a plurality of different private-public key pairs, and the certificate may include flags to designate which of the plurality of public keys the receiver should use to decrypt respective certificates. A certificate for application providers will nominally include: CERTIFICATE.sub.-- FLAGS (which identify the certificate type and may include the system controller's public key flag); PROVIDER.sub.-- ID, (which indicate length of provider ID); PROVIDER.sub.-- EXPIRE, (which indicates application lifetime); PROVIDER.sub.-- AUTHORIZATION.sub.-- FLAGS, PROVIDER.sub.-- STORAGE.sub.-- LIMIT, (which indicates allotted receiver memory); PROVIDER.sub.-- NAME, (the application provider's name) PROVIDER.sub.-- FIXED.sub.-- CERT, (which is the providers public key). This foregoing certificate information is hashed modulo 128, and the hash value is appended thereto. The CERTIFICATE.sub.-- FLAGS mentioned above include authorization flags which grant/deny the receiver processors access to privileged actions. Examples of representative privileges accessed via flags are listed immediately below and include; 1. the ability to be downloaded from a broadcast link; 2. the ability to be downloaded from a local link (e.g. connected via a local IRD port); 3. the ability to be downloaded from a local remote link (e.g. via a telephone link); 4. The ability for an application to switch tracks in the context of the same program (e.g. to switch between video tracks 1 and 2); 5. the ability to establish a broadcast connection (e.g. to change TV programs or channels); 6. the ability to establish a local connection; 7. the ability to establish a remote connection; 8. the ability to control external devices; 9. the ability to download unchecked modules; 10. the ability for an application to use cryptographic features: 11. the ability for an application to request the user for permission to access files which have user restrictions; and 12. the ability to activate a resident OCODE monitor for remote debugging. These flags are part of both the provider certificate and the application authorization field directory. An application must have the authorization flags set at both locations before it is permitted to perform the privileged action. Respective receivers contain a BOX authorization mask, in nonvolatile storage, which is programmed to permit access to particular privileges, or to prevent certain privileged actions. Each application provider selects his own cryptographic public-private key pair, and has his public key certified by the AVI system controller (for example by notarized request). The application provider is constrained by certain guidelines in selecting the public key. The constraints relate to the capabilities of the receiver hardware. In particular, near term consumer electronic receivers will include minimal memory and relatively unsophisticated processors, factors which affect authentication processing speeds and times, and thus the size and form of public keys. Examples of constraints may be that public keys are to be 512 bits or less and that the number of bits be a power of two etc. A special group AVI system ID may be reserved for programs designed to perform receiver or system maintenance. This system ID will be attached with a service provider ID. If a program contains both the special group ID and an authentic provider ID, the corresponding maintenance program may obtain access to more secure portions of the receiver, depending upon the ID of the particular provider. For example the application provider may be the system controller and the attached application may be for updating entitlements in a smart card, or performing a system performance check. Alternatively, the application provider may be associated with impulse buying commercials and the program may be related to checking a users debits against his credit, or to facilitate revenue collection, etc. On the other hand, if a group ID is not the special group AVI system ID, the functions available to the application may be limited to functions available to all applications. Manufacturers of particular receiver apparatus may be assigned special manufacturer ID's. Any application having the manufacturer ID may be authenticated by a special authentication process, resident in the receiver, and implemented by the manufacturer during assembly of the receiver. Programs containing the manufacturer ID will access only receivers produced by the particular manufacturer, and may function to access a particular set of functions built into the receiver by the manufacturer. This type of application may be utilized to upgrade receiver operating software. There may also be network operators who have software/hardware resident in particular receivers. These network operators may also be assigned special ID's to allow selective access to the software/hardware of all network receivers. The network operators may include their own authentication process resident in the software/hardware of the network receiver. Whether an application is a special system type, or a manufacturer type or a network type is indicated in the Directory Module (Table II) in the Application Type field. The Application Qualifier field may include information identifying the manufacturer, or network operator, etc. Security is applied to an application as follows. After an application provider has generated an application and formed respective modules including the Directory module, he determines which parts of the application are to be protected. In all instances the Directory Module will be protected. In addition each module containing an entry point will be protected. Modules without entry points are protected at the providers discretion, and Data Modules are protected at the providers discretion. It should be recognized that portions of the data in data modules may frequently change, and thereby put a relatively heavy security processing burden on the encoder and receiver, if Data Modules are protected. Therefor Data Modules may frequently be transmitted unprotected. Having selected the modules to be protected, the provider forms a list of the modules selected for security protection, and the mode of protection for respective modules, and enters this list in the Directory Module in the fields designated security information. In a particular AVI system this module list may be included in general directory information i.e., the first security information portion of the Directory Module. In an alternative AVI system, information indicating whether a particular module is protected may be included only in the further security information fields of the respective module in the directory. Part of the receiver system programming will include a routine to examine the Directory for module security information, and perform security processing on respective modules according to this information. Module protection may take several forms. The first is simply to encrypt the selected module with the application providers private key. A second method is to perform a "hash" function over the module and include the "hash" value in the Directory Module in the further security information field for the respective module. A third method is to perform a hash function over the module, include the hash value in the Directory Module and encrypt the selected module with the application providers private key. A fourth method performs a hash function over the selected module, attaches the hash value to the module, encrypts the module plus hash value, and places a replica of the encrypted hash value in the Directory Module. In each of the foregoing examples, security processing of the Directory Module is done after all other modules are processed and the security information for respective modules has been entered in the Directory Module. The preferred method comprises performing hash functions over respective modules, inserting the respective hash values in the further security information fields of the directory module and subsequently performing a hash function over the Directory Module. The hash Value of the Directory Module is then encrypted with the providers private key. A trusted application provider will be assigned a signed certificate which includes items such as the providers public key, the providers ID, an expiration date of the certificate, possibly the amount of storage allocated the provider at the receiver etc. This certificate is signed with the system controller's private key. The encrypted hash value is appended to the signed certificate and the combination is appended to the Directory Module. The directory Module and all other modules are provided to the system controller in plaintext. Data Modules which are selected for protection and which are frequently changing, are protected by means of a signature of the provider on the hash value over the Data Module, which signature is made part of the respective module. It is possible that the application provider is in fact an overseer of a subgroup of lesser application providers. In this instance, the application provider may provide a sub-certificate signed with the application providers private key and including a sub-providers public key, the sub-providers ID, an expiration date of the certificate, possibly the amount of storage allocated the sub-provider at the receiver etc. This sub-certificate will also be appended to the Directory Module along with the certificate assigned the application provider. The preferred mode of protection is not secure in that it does not preclude prying eyes from detecting/interpreting the transmitted information. However the protection, i.e., inclusion of the certificate and hashing of the data, is advantageously simple to perform and does provide assurance that the data comes from an authorized source and that the integrity of the received data is insured, (if authenticated at the receiver). Untrusted application providers, i.e., providers who may be careless in application generation and threaten the integrity of an AVI service, are not provided certificates to be appended their respective applications. Applications provided by untrusted providers are subjected to certification by a trusted certifying authority. The certifying authority may inspect the integrity of the application and then process the applications of the untrusted application providers for protection purposes, and ultimately pass the processed application to the system controller. Security processing will be further described with reference to FIGS. 1 and 5. FIG. 1 includes distinct hashing and encrypting elements 29, and 30, however it will readily be recognized, by ones skilled in the art of digital signal processing, that both functions may be performed in software executed by the .mu.PC or digital signal processor, DSP, which may be included in the element 10. Once the application has been generated and stored {40} in the memory 11, the programmer will select/determine {41} the modules which are to be security protected. These modules will be tagged with an index (i). The Directory Module is assigned the highest index so that it will be processed last. Each module to be processed is assigned a "Change" flag which is set to a "1". The AVI system repeatedly transmits the application during an AVI program. Nominally Code and some Data Modules remain unchanged during the program, but some e.g., Data Modules may change. During the repeated transmissions of the application it is preferred not-to re-process unchanged modules for security, but rather only to reprocess the modules which actually change. The "Change" flags are established to alert the security processing function which modules require re-processing clue to changes during the duration of a program. Initially the "Change" flag of each module to be security protected is set to the change mode. The element 10 also determines if a certificate from the system controller is available. An operating index "i" is set to zero {42} and the first module, M(O), is accessed {43} from the memory 11. The "Change" flag for the module is tested {44} and reset {45}. If the module has been previously processed and the "Change" flag indicates no change, the system jumps to step {56}, increments the index "i" and accesses the next module. If the "Change" flag indicates that a change has occurred in the module, it is applied {46} to a HASH function processor 29. The particular hash function is maintained relatively simple to limit processing requirements imposed on respective receivers. The function is preferably a one-way function. The hash function should be computationally fast and extremely difficult to decipher or break. An exemplary hash function is based on a vector W of 256 codewords w.sub.x each 128 bits in length. Data to be hash processed (hashed) is segmented into 256-bit exclusive blocks of data D, where D=d.sub.1, d.sub.2, d.sub.3, d.sub.4, d.sub.256. A basic hash function BH(D) is defined: ##EQU1## If there are n blocks of data D, n values, B.sub.1, B.sub.2, B.sub.3, B.sub.n, each 128 bits in length, of the function BH(D) will be generated. To compute the hash over the whole data, the intermediate results B.sub.i are combined as follows: Let <Bi,Bj> represent the 256 number obtained by concatenating the 128 blocks Bi and Bj. Then define H(D), the hash over the data as; H(D)=BH(<BH(. . . (<BH(<BH(<B.sub.1,B.sub.2 >),B.sub.3 >),B.sub.4 >), . . . ), B.sub.n >). Alternatively the function H(D) may be of the form; H(D)=B.sub.1 XOR B.sub.2 XOR B.sub.3 XOR . . . B.sub.n. A preferred hash function for hashing modules, is the publicly known function MD5 (MD stands for Message Digest and MD5 is described by R. Rivest, THE MD5 MESSAGE DIGEST ALGORITHM, RFC 1321, April 1992). Once the module is hashed, the module is tested {47} to determine if it is expected to be changing during the program. If it is expected to change, the hash value H(D) is not placed in the directory, by rather is appended {48} to the module stored in the memory 11. (Alternatively, the hash value may be signed (encrypted) with the providers private key, and then appended to the module stored in memory 11). The index i is incremented {56} and the next module is accessed from memory. If at {47} the module is determined not to change, a test {49} is made to determine if the module is the Directory Module. If it is not, the hash value H(M(i)) for module M(i) is placed in the Directory Module {50} in either the first security information field, or in the further security information field for the respective module. The index i is incremented {56} and the next module is accessed from memory. If at test {49} the module is determined to be the Directory Module, the hashed value H(M(i)) is applied to the encryptor 30 wherein it is encrypted with the application providers private key. (If desired, the entire Directory Module may be applied to the encryptor for encryption at this juncture.) The certificate is fetched {52} and the encrypted hash value is appended thereto {53}, and the certificate with the hash value appended is attached {54} to the Directory Module in memory 11. A flag is set {55} which indicates to the data packet processor/program controller, that the program is ready for transmission. The system jumps to step {42} and the index is reset to zero. The system then proceeds to check if modules change and only changed modules are rehashed, during repeat transmissions of the application during a program. As noted earlier, an application provider may include other signed information/certificates which may be appended to the Directory Module. Signing of such information is performed in the encryptor 30 using the providers private key. In an alternative embodiment, the encryption step 51 may be eliminated. In a still further embodiment, all hash values for all hashed modules may be encrypted. FIG. 12 illustrates the format of a preferred Directory Module. The Directory Module is in plain text. Only the Directory signature (hash value) and the certificate are encrypted, the former with the provider's key and the latter with the system controller's key. In addition, when respective modules are hashed, each such module may be preceded with an ASCII version of some predetermined text associated with the system controller/provider such as the text "OpenTv(.TM.)" before hashing, so that respective module signatures are, for example, the hash value H(OpenTv(.TM.)+Module), and the Directory Module signature is the encrypted value of H(OpenTv(.TM.)+Directory Module). This is indicated in FIG. 1 with the box OTV attached to the memory 11, and is meant to imply that a digital version of the text "OpenTv(.TM.)" is stored therein and may be multiplexed with the respective modules when they are read out and applied to the hash function element 29. The Directory Module in FIG. 12 illustrates the preferred format for the AVI system designated OpenTv.TM. being developed by Thomson Consumer Electronics Inc. The formats of certificates, public keys and signatures used therein are described immediately below. All certificates, keys and signatures will have multiple byte fields in BIG-ENDIAN format. This architecture independent format facilitates portability across different receiver architectures. Any OpenTV certificate is a combination of a fixed structure followed by a variable length part, which includes the public key being certified and the signature of the OpenTV controller. There are two classes of certificates that will be issued by the OpenTV controller. 1. Producer(provider) Certificates which are given to application producers. 2. Server (system controller) Certificates which are specific to a transaction server to which applications from a producer (provider) can establish secure communications. In addition, a USER certificate may be issued by the controller. This certificate will never be parsed internally by OpenTV, but only made available to the external world. The OpenTV system will only know the size of this certificate. Apart from an Open TV specific 4 byte header, the remainder of the certificate structure may be maintained confidential, and may be a standard X.509 certificate. The following are the sizes for common parts of certificates. CERTIFICATE.sub.-- FLAGS.sub.-- LENGTH (4 bytes) PUBLC.sub.-- KEY.sub.-- SIZE.sub.-- LENGTH (4 bytes) An OpenTV controller issued certificate starts with a 32-bit flag structure which describes the certificate. The location and meaning of the various flags are described thusly. The flag for possible extensions to the OpenTV certificate structure is set for the Basic Open TV certificate; not to be set for extensions. The flags are defined as follows ##STR1## Exactly one of the following 3 flags will be set. ##STR2## There is divergence between the SERVER/PRODUCER certificates and the USER certificates as to the interpretation of the 32 bit field. If the certificate has the appearance of a USER certificate then the last 16 bits of the field are actually its size including the initial 32 bit field. Regarding the SERVER/PRODUCER flags, after examining the first four bits, the entity being certified is known, or the certificate is considered to be an extension beyond the current system. The next four bits indicate which OpenTV controller public key has been used to generate the signature. They represent a number N from 0-15. If 0.ltoreq.N.ltoreq.14, the N'th embedded public key is to be used. If N==15 then the public key to be used is the latest key received through an EXTERNAL trusted channel. Internally in the system the key numbers can only increase. That is, if internally the key is 5 and a certificate with key 6 occurs and is verified, then the internal key becomes 6 and certificates with keys less than 6 will not be accepted. Finally, if and when all internal keys break, the public key would be accepted only from EXTERNAL trusted channel. The next byte is reserved for a description of the certificate. Currently it is unused. The next two bytes provide information about the Producer/Server and the Key being certified. The first byte contain flags describing the algorithm with respect to the public key; this is common to both server and producer. The next and last byte are different for Producer and Server so they are described separately. The algorithm byte flags are: ##STR3## The last byte for the PRODUCER certificate currently has no flags defined. The last byte for SERVER certificate currently has one flag defined to indicate whether the server is constrained. From a functional standpoint, the constrained server does not require any information about the connecting party when it first establishes a secure link. This makes link establishment much faster. ##STR4## The externally available fixed part of a Producer Signature consists of a two byte flags field which specifies the type of signature, and a 2 byte field which gives the size of the signature. PRODUCER.sub.-- SIGNATURE.sub.-- FLAGS.sub.-- LENGTH (2 bytes) PRODUCER.sub.-- SIGNATURE.sub.-- SIZE.sub.-- LENGTH (2 bytes) Currently only one flag is meaningful, the assisted flag. If the producer's signature algorithm is RSA.sub.-- 3.sub.-- WITH.sub.-- MD5, as specified in the certificate for the producer then the producer has the option of adding additional help data after the signature for faster checking, and this is designated ##STR5## The Public Key Structure (for RSA) for producers, servers and OpenTV boxes will now be described. For portability, the modulus and exponent sizes MUST BE A MULTIPLE of 4 BTYES. Also OpenTv requires that if a modulus size is stated to be S bytes, then the first 32 bits of the modulus when represented in big endian format must be NON ZERO. This is not a limitation since the size can then be stated to be S-4 or less. The public key consists of: fixed.sub.-- public..sub.-- key.sub.-- t, followed by exponent (in big-endian byte format) followed by modulus (in big-endian byte format) A producer/server certificate consists of a cleartext part which contains a descriptor of the certificate by the OpenTV controller followed by the public key of the producer/server of data type described above. In addition there is an enciphered part which is the digital signature S of the OpenTV controller on data which depends on the cleartext data. A producer/server at this stage has a choice of either using only S or adding additional data (e.g., Q1 and Q2) beyond the signature to make it easier to check. The producer/server needs to add 4 bytes of information between the Cleartext and the Signature S, and possibly some information beyond S to assist in checking. The 4 bytes of information include fields for flags and the size of the total amount of data consisting of the signature and help information. The sizes of these two fields are: CERTIFICATE.sub.-- SIGNATURE.sub.-- INFO.sub.-- FLAGS.sub.-- LENGTH(2 bytes) CERTIFICATE.sub.-- SIGNATURE.sub.-- SIZE.sub.-- LENGTH (2 bytes) Only one flag is currently defined, the RSA.sub.-- 3.sub.-- ASSIST flag. If set, there is help information beyond the signature S, which are the two quotients Q1, Q2 described herein above. This flag is defined; ##STR6## The foregoing describes the state of encryption at the module level. This may be overlain with a further encryption at the transport packet level. That is, when respective modules are divided into transport packet payloads for transmission, the payloads may be encrypted independent of the authentication process. Returning to the general description of the system, two way communications between providers and receivers, by telephone modem for example, will incorporate encrypted communications using RSA or Data Encryption Standard, DES cryptography for example. The session key will be set up using public key cryptography. An application must present a certified version of the public key of the server with which it wishes to communicate. A session key is established only if the application provider's ID matches the server ID on the certificate, and the key exchange will use the public key contained in the certificate. FIG. 8 illustrates in block form, a portion of AVI signal receiver or IRD including elements of an inverse transport packet processor. Signal is detected by an antenna 80 and applied to a tuner detector, 81, which extracts a particular frequency band of received signals, and provides a baseband multiplexed packet signal. The frequency band is selected by the user through an IRD system controller 89 (hereafter IRD controller) by conventional methods. Nominally broadcast AVI signals will have been error encoded using, for example, Reed-Solomon forward error correcting (FEC) coding. The baseband signals will thus be applied to a FEC decoder, 82. The FEC decoder 82 synchronizes the received video and provides a stream of signal packets of the type illustrated in FIG. 3. The FEC 12 may provide packets at regular intervals, or on demand, by for example, memory controller 87. In either case a packet framing or synchronizing signal is provided by the FEC circuit, which indicates the times that respective packet information is transferred from the FEC 82. Only packets from a single AVI signal may be processed by the receiver at one time. In this example it is assumed that the user has no knowledge of which packets to select. This information is contained in a program guide, which is a special program consisting of data which interrelates program signal components through their respective SCID's. The program guide is a listing for each program, including the SCID's for the audio, video, and data components of respective programs. The program guide (packets D4 in FIG. 2) is assigned a fixed SCID. When power is applied to the receiver, the IRD controller 89 is programmed to load the SCID associated with the program guide into a SCID detector 84, which may be a bank of matched filters. When the program guide SCID is detected, the memory controller 87 is conditioned to route the corresponding packet payload to a predetermined location in the memory 88 for use by the IRD controller. The IRD controller waits for a programming command from the user via an interface 90, which is shown as a keyboard, but which may be a conventional remote control, or receiver front panel switches. The user may request to view a program provided on channel 4 (in the vernacular of analog TV systems). The IRD controller 89 is programmed to scan the program guide list that was loaded in the memory 88 for the respective SCID's of the channel 4 program components, and to load these SCID's in the SCID detector 84. Received packets of audio, video or data program components, for a desired program, must ultimately be routed to the respective audio 93, video 92, or auxiliary data 91, (94) signal processors respectively. The data is received at a relatively constant rate, but the signal processors nominally require input data in bursts (according to the respective types of decompression for example). The exemplary system of FIG. 8, first routes the respective packets to predetermined memory locations in the memory 88. Thereafter the respective processors 91-94 request the component packets from the memory 88. Routing the components through the memory provides a measure of desired signal data rate buffering or throttling. The audio, video and data packets are loaded into respective predetermined memory locations to enable the signal processors easy access to the component data. Payloads of respective component packets are loaded in the appropriate memory areas as a function of the corresponding SCID's, and control signals provided by the SCID detector. This association may be hardwired in the memory controller 87, or the association may be programmable. The respective signal packets are coupled from the FEC 82 to the memory controller 87 via a signal descrambler 86. Only the signal payloads are scrambled and the packet headers are passed by the descrambler unaltered. Whether or not a packed is to be descrambled is determined by the CF flag (FIG. 3) in the packet prefix, and how it is to be descrambled is directed by the CS flag. This packet scrambling is independent of the application module security processing described above. The descrambling apparatus may be realized with conventional decryption apparatus, and may be utilized to perform decryption of received certificates and other data as required. However in the following description of processing transmitted applications, decryption is performed by other apparatus. An AVI system may include a number of devices capable of operating with the PC-data portion of an AVI signal. For example in FIG. 8 both of the AUX1 and AUX2 processors may be responsive to the PC-data portion of an AVI signal. The AUX1 processor may be a personal computer, PC, arranged to detect transmitted stock market data and to manipulate same with a transmitted interactive application. AUX2 may be a television system arranged to permit interactive impulse buying in conjunction with transmitted interactive commercials. Note, interactivity may be facilitated with the aid of a telephone modem (not shown) interconnected with FIG. 8 system. In addition the IRD controller 89 may be programmed to process and execute transmitted applications, particularly for system maintenance. The receiver functions related to execution of transmitted interactive applications will be described in the context of the IRD controller 89 operating with the transmitted application. (It should be noted, that interactivity does not necessarily mean that the user interacts with the provider, though this is one aspect of interactivity. Interactivity also includes the concept of a user being able to affect the signal/system at the user's end of the system in accordance with a transmitted application, particularly in the realm of educational programs.) FIG. 9 shows the IRD controller of FIG. 8 in more detail. The IRD controller 89 is shown with a Hash function processor 96, a decryptor 97, a modem 98 and an EPROM 99. The hash function generator 96 and the decryptor 97 may be realized in either hardware or software. The controller processor (.mu.PC) may include random access memory, RAM, and read only memory ROM, for programming general system instructions. Other system instructions are contained in the EPROM 99. The ROM and the EPROM are programmed at manufacture so that the system is operable. However in this example, the EPROM may be reprogrammed to update system functions via an interactive transmitted program. Assume that at manufacture, the system is programmed to look for a system maintenance SCID between 1:00 AM and 4:00 AM on mornings that the receiver is not in use, so that the system provider can update respective receivers with new system enhancements. Between 1:00 AM and 4:00 AM on mornings that the receiver is not in use, the .mu.PC will program the SCID detector to look for packets that contain the system maintenance SCID, and prepare the memory 88 to receive program data. An example of program module detection is illustrated in FIG. 10. The programming for SCID detection and memory preparation is part of the start up processes {100}. Once the SCID detector is programmed the system idles {102} until a packet containing the system maintenance SCID is detected. When such packet is detected, the packet is tested {104} to determine if it contains a transmission unit or module header. If it does not, the packet is discarded and the system waits {102} for the next application packet. It is assumed that the information necessary to load any application program is self contained in the program (TU headers or Directory Module header), hence the system is constrained not to load any detected packets until a packet with the appropriate header information is available. When an appropriate packet is detected, its payload is loaded {106} in the memory 88. The system waits {108} for the next system maintenance packet, and when it is detected it is loaded {110} in the memory 88. A test {112} is made after each packet is loaded in memory to determine if a complete module has been loaded. If the module is not complete, the system jumps back to step {108} to await the next packet. If the module is complete such is noted in a listing {114}. A further test is made {116} to determine if the completed module is a Directory Module. If it is, the system will immediately attempt to authenticate the application provider. The certificate appended to the Directory Module is decrypted {122} and its contents are checked {124}. If the contents of the certificate are not authentic, a warning display is activated to inform the user that an unauthorized provider was detected. At this point a number of alternatives are possible, including a) restarting the process at step {100}; b) shutting down the process for twenty four hours; c) discarding the Directory Module and waiting for the next Directory Module; etc. FIG. 11 shows the authentication process in more detail. If at test {16} a Directory Module is detected, the certificate and encrypted hash value appended to the module are accessed {1221}. The certificate is applied to the decryptor 97 and decrypted {1222} using the AVI system controller's public key which has been previously distributed to respective receivers and stored in the receiver. The decrypted certificate is applied to the .mu.PC {1241}. The .mu.PC accesses corresponding items from the EPROM, and compares {1242} relevant corresponding items. For example the certificate will include an ID which is compared against a list of authorized ID's. In addition the certificate may include an expiration time and date which is compared against the current time and date etc. If the compared items check {1243} against corresponding items stored in the receiver, the application provider's public key, which was transmitted in the certificate, is applied to the decryptor and used to decrypt {1244} the encrypted hash value appended to the Directory Module, or to decrypt any other encrypted data provided by the application provider. (At this juncture, if the entire Directory Module is encrypted, it may be accessed from memory and decrypted while the application provider's public key is applied to the decryptor.) On the other hand, if the compared items prove not to be authentic or the certificate has expired, the warning is displayed {130}. If the application provider is proven to be authentic, the Directory Module is applied to the hash function element 96 and hashed {126}, and the hash value is compared {128} in the .mu.PC with the decrypted Directory Module hash value that was appended to the Directory Module. (In the preferred embodiment an ASCII version of some predetermined text which is associated with the system controller/provider e.g., "OpenTv(.TM.)", will be attached to precede respective modules before hashing so that respective hash values will equal, for example, H(OpenTv(.TM.)+Module). This is indicated in FIG. 9 by the box OTV attached to the memory 88, and is meant to imply that a digital version of the text "OpenTv(.TM.)", for example, may be stored in memory 88, and multiplexed with the Directory Module when it is read from the memory.) If the hash values are not identical, the Directory Module is presumed to include errors and is discarded from memory, and the fact that the module was previously loaded is erased {134} from the listing {114}, and the system returns to the step {108} to wait for the next packet. If the hash value of the Directory Module agrees with the appended hash value, the hash values for respective program modules are retrieved {129} from the directory for use in checking the integrity of received program modules. The system jumps to step {118} which tests whether all program modules have been loaded in memory. If they have not, memory addressing for the next module is arranged {120} and the system returns {108} to await the next appropriate packet. If the test at {118} indicates that the application program is completely stored in memory, the respective program modules are checked for transmission integrity. Respective modules are accessed {136} from memory, applied to the hash function element 96, and hashed {138}. The respective hash values are compared {140} in the .mu.PC with the corresponding hash values transmitted in the Directory Module, or appended to the particular module under test. If the hash values do not agree, the module is presumed to contain errors and is discarded {150, 152}, else a test is made {142} to determine if all modules have been checked. If they have all been tested, a check is made {146} to determine if a complete security checked application is resident in memory. If not, the system is returned to step {120} to start loading a new module. If the application is complete, it is executed {148}. In this example the program will instruct the .mu.PC to access particular data in a program Data Module and reprogram the EPROM with the transmitted data. Once execution has begun, the system is programmed to continue to extract program packets from the transmitted signal. On reception, respective headers are examined for version number. If the version number for a particular module changes, this module will be hash processed, and if the hash value checks, the module with the new version number will be substituted for the prior corresponding module. As indicated, different apparatus in the receiving apparatus may utilize a particular transmitted application, and may be programmed to perform the requisite security processing prior to execution of the application. In the preferred embodiment, to avoid duplication of programming or hardware, the security processing is performed by the IRD controller. The IRD controller will be alerted when security processing need be performed by information contained in the program guide.
|
Same subclass Same class Consider this |
||||||||||