US20070211292A1 - Method Of Storing Code Segements In Plural Printer Cartridges - Google Patents

Method Of Storing Code Segements In Plural Printer Cartridges Download PDF

Info

Publication number
US20070211292A1
US20070211292A1 US11/749,123 US74912307A US2007211292A1 US 20070211292 A1 US20070211292 A1 US 20070211292A1 US 74912307 A US74912307 A US 74912307A US 2007211292 A1 US2007211292 A1 US 2007211292A1
Authority
US
United States
Prior art keywords
key
bit
attacker
memory
keys
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11/749,123
Inventor
Simon Walmsley
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Zamtec Ltd
Original Assignee
Silverbrook Research Pty Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Silverbrook Research Pty Ltd filed Critical Silverbrook Research Pty Ltd
Priority to US11/749,123 priority Critical patent/US20070211292A1/en
Assigned to SILVERBROOK RESEARCH PTY LTD reassignment SILVERBROOK RESEARCH PTY LTD ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: WALMSLEY, SIMON ROBERT
Publication of US20070211292A1 publication Critical patent/US20070211292A1/en
Assigned to ZAMTEC LIMITED reassignment ZAMTEC LIMITED ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: SILVERBROOK RESEARCH PTY. LIMITED AND CLAMATE PTY LIMITED
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14Protection against unauthorised use of memory or access to memory
    • G06F12/1408Protection against unauthorised use of memory or access to memory by using cryptography
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/72Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in cryptographic circuits

Definitions

  • the present invention relates to the storage of bit-patterns in non-volatile memory of a printer cartridge.
  • the invention has been developed primarily for storing one or more keys in an integrated circuit, and will be described with reference to this application. However, it will be appreciated that the invention can be applied in a number of other fields where it is desirable to store bit-patterns in non-volatile memory.
  • non-volatile memory such as flash memory on an integrated circuit
  • the same key needs to be stored in multiple integrated circuits, many of which are available to a potential attacker.
  • the integrated circuit can form part of a consumable such as an ink cartridge, which are widely distributed as replacements for empty cartridges.
  • a focussed ion beam FIB write attack One way in which an attacker can probe an integrated circuit (or chip) for a key or other secret information is to use a focussed ion beam FIB write attack.
  • encapsulant is carefully removed from the circuitry and a FIB used to change one or more bits in flash memory from an unknown state into a known state.
  • an attacker may be able to deduce certain information about the state of the attacked bit or bits. For example, if the chip no longer works, it may be determined that the state of the bit or bits was changed by the FIB.
  • the attacker merely obtains another chip that has an identical secret key, and attempts a similar attack on a different bit or combination of bits. By repeating the attack on different bits over a number of the chips, the attacker can either directly determine the key, or can build up a statistical model that vastly reduces the number of attempts needed to crack the security offered by the key on the chip. Of course, once the key is compromised in this way, it is compromised for all other chips having this key.
  • the present invention provides a method of storing at least one functionally identical code segment in each of a plurality of printer cartridges of a printing system, each of the printer cartridges having a memory, the method comprising, for each printer cartridge:
  • At least one of the code segments in each of the printer cartridges includes an initial instruction, the initial instruction being located at an initial instruction location, the initial instruction location being the same in all the printer cartridges.
  • the initial instruction in each printer cartridge is indicative of the first memory location of that printer cartridge, the initial instruction is indicative of the first memory location by including an explicit reference to the memory location, and the initial instruction is indicative of the first memory location by including an implicit reference to the memory location.
  • the implicit reference is a pointer to a location at which the address of the first memory location is stored, and the implicit reference is a pointer to a register that holds the address of the first memory location.
  • step (a) includes randomly selecting the first memory location, includes selecting the first memory location based on a stochastic process or mechanism, and selecting the first memory location from an existing list or sequence of memory locations.
  • each memory is incorporated in a quality assurance chip of each printer cartridge, and is non-volatile memory.
  • a first bit-pattern is stored in non-volatile memory of a printer cartridge, and the method comprising:
  • a bit-pattern is stored in each of a plurality of printer cartridges, each of the printer cartridges having a memory, the method comprising, for each printer cartridge:
  • first memory locations are different in at least a plurality of the respective printer cartridges.
  • multiple first bit-patterns are stored in non-volatile memory of a printer cartridge, the method comprising, for each of the first bit-patterns to be stored:
  • the present invention provides one or more printer cartridges having a bit-pattern and/or result stored therein in accordance with the method.
  • FIG. 1 Single SoPEC A4 Simplex system
  • FIG. 2 Dual SoPEC A4 Simplex system
  • FIG. 3 Dual SoPEC A4 Duplex system
  • FIG. 4 Dual SoPEC A3 simplex system
  • FIG. 5 Quad SoPEC A3 duplex system
  • FIG. 6 SoPEC A4 Simplex system with extra SoPEC used as DRAM storage
  • FIG. 7 SoPEC A4 Simplex system with network connection to Host PC
  • FIG. 8 Document data flow
  • FIG. 9 Pages containing different numbers of bands
  • FIG. 10 Contents of a page band
  • FIG. 11 Page data path from host to SoPEC
  • FIG. 12 Page structure
  • FIG. 13 SoPEC System Top Level partition
  • FIG. 14 Proposed SoPEC CPU memory map (not to scale)
  • FIG. 15 Possible USB Topologies for Multi-SoPEC systems
  • FIG. 16 CPU block diagram
  • FIG. 17 CPU bus transactions
  • FIG. 18 State machine for a CPU subsystem slave
  • FIG. 19 Proposed SoPEC CPU memory map (not to scale)
  • FIG. 20 MMU Sub-block partition, external signal view
  • FIG. 21 MMU Sub-block partition, internal signal view
  • FIG. 22 DRAM Write buffer
  • FIG. 23 DIU waveforms for multiple transactions
  • FIG. 24 SoPEC LEON CPU core
  • FIG. 25 Linking Printhead Concept
  • FIG. 26 Equivalent signature generation
  • FIG. 27 An allocation of words in memory vectors
  • FIG. 28 Transfer and rollback process
  • printhead module and “printhead” are used somewhat interchangeably.
  • a “printhead” comprises one or more “printhead modules”, but occasionally the former is used to refer to the latter. It should be clear from the context which meaning should be allocated to any use of the word “printhead”.
  • SoPEC ASIC Small office home office Print Engine Controller
  • the SoPEC ASIC is intended to be a relatively low cost solution for linking printhead control, replacing the multichip solutions in larger more professional systems with a single chip.
  • the increased cost competitiveness is achieved by integrating several systems such as a modified PEC1 printing pipeline, CPU control system, peripherals and memory sub-system onto one SoC ASIC, reducing component count and simplifying board design.
  • SoPEC contains features making it suitable for multifunction or “all-in-one” devices as well as dedicated printing systems.
  • the SoPEC device can be used in several printer configurations and architectures.
  • SoPEC-based printer architecture will contain:
  • the Host PC rasterizes and compresses the incoming document on a page by page basis.
  • the page is restructured into bands with one or more bands used to construct a page.
  • the compressed data is then transferred to the SoPEC device directly via a USB link, or via an external bridge e.g. from ethernet to USB.
  • a complete band is stored in SoPEC embedded memory. Once the band transfer is complete the SoPEC device reads the compressed data, expands the band, normalizes contone, bi-level and tag data to 1600 dpi and transfers the resultant calculated dots to the linking printhead.
  • the SoPEC device can print a full resolution page with 6 color planes.
  • Each of the color planes can be generated from compressed data through any channel (either JPEG compressed, bi-level SMG4 fax compressed, tag data generated, or fixative channel created) with a maximum number of 6 data channels from page RIP to linking printhead color planes.
  • mapping of data channels to color planes is programmable. This allows for multiple color planes in the printhead to map to the same data channel to provide for redundancy in the printhead to assist dead nozzle compensation.
  • a data channel could be used to gate data from another data channel.
  • data from the bilevel data channel at 1600 dpi can be used to filter the contone data channel at 320 dpi, giving the effect of 1600 dpi edged contone images, such as 1600 dpi color text.
  • the SoPEC device typically stores a complete page of document data on chip.
  • the amount of storage available for compressed pages is limited to 2 Mbytes, imposing a fixed maximum on compressed page size. SoPEC would not be capable of printing worst case pages unless they are split into bands and printing commences before all the bands for the page have been downloaded.
  • the page sizes in the table are shown for comparison purposes and would be considered reasonable for a professional level printing system.
  • the SoPEC device is aimed at the consumer level and would not be required to print pages of that complexity. If a document with more complex pages is required, the page RIP software in the host PC can determine that there is insufficient memory storage in the SoPEC for that document. In such cases the RIP software can take two courses of action:
  • SoPEC Once SoPEC starts printing a page it cannot stop; if SoPEC consumes compressed data faster than the bands can be downloaded a buffer underrun error could occur causing the print to fail.
  • a buffer underrun occurs if a line synchronisation pulse is received before a line of data has been transferred to the printhead.
  • the SoPEC is a page rendering engine ASIC that takes compressed page images as input, and produces decompressed page images at up to 6 channels of bi-level dot data as output.
  • the bi-level dot data is generated for the Memjet linking printhead.
  • the dot generation process takes account of printhead construction, dead nozzles, and allows for fixative generation.
  • a single SoPEC can control up to 12 linking printheads and up to 6 color channels at >10,000 lines/sec, equating to 30 pages per minute.
  • a single SoPEC can perform full-bleed printing of A4 and Letter pages.
  • the 6 channels of colored ink are the expected maximum in a consumer SOHO, or office Memjet printing environment:
  • SoPEC is color space agnostic. Although it can accept contone data as CMYX or RGBX, where X is an optional 4th channel (such as black), it also can accept contone data in any print color space. Additionally, SoPEC provides a mechanism for arbitrary mapping of input channels to output channels, including combining dots for ink optimization, generation of channels based on any number of other channels etc. However, inputs are typically CMYK for contone input, K for the bi-level input, and the optional Netpage tag dots are typically rendered to an infra-red layer. A fixative channel is typically only generated for fast printing applications.
  • SoPEC is resolution agnostic. It merely provides a mapping between input resolutions and output resolutions by means of scale factors. The expected output resolution is 1600 dpi, but SoPEC actually has no knowledge of the physical resolution of the linking printhead.
  • SoPEC is page-length agnostic. Successive pages are typically split into bands and downloaded into the page store as each band of information is consumed and becomes free.
  • SoPEC provides mechanisms for synchronization with other SoPECs. This allows simple multi-SoPEC solutions for simultaneous A3/A4/Letter duplex printing. However, SoPEC is also capable of printing only a portion of a page image. Combining synchronization functionality with partial page rendering allows multiple SoPECs to be readily combined for alternative printing requirements including simultaneous duplex printing and wide format printing.
  • the required printing rate for a single SoPEC is 30 sheets per minute with an inter-sheet spacing of 4 cm. To achieve a 30 sheets per minute print rate, this requires:
  • a printline for an A4 page consists of 13824 nozzles across the page.
  • 13824 dots of data can be generated in 69.2 ⁇ seconds. Therefore data can be generated fast enough to meet the printing speed requirement.
  • the data must be transferred to the printhead.
  • SoPEC device consists of 3 distinct subsystems
  • the CPU subsystem controls and configures all aspects of the other subsystems. It provides general support for interfacing and synchronising the external printer with the internal print engine. It also controls the low speed communication to the QA chips.
  • the CPU subsystem contains various peripherals to aid the CPU, such as GPIO (includes motor control), interrupt controller, LSS Master, MMI and general timers.
  • GPIO includes motor control
  • interrupt controller includes interrupt controller
  • LSS Master interrupt controller
  • MMI general timers
  • the CPR block provides a mechanism for the CPU to powerdown and reset individual sections of SoPEC.
  • the UDU and UHU provide high-speed USB2.0 interfaces to the host, other SoPEC devices, and other external devices.
  • the CPU supports user and supervisor mode operation, while the CPU subsystem contains some dedicated security components.
  • the DRAM subsystem accepts requests from the CPU, UHU, UDU, MMI and blocks within the PEP subsystem.
  • the DRAM subsystem (in particular the DIU) arbitrates the various requests and determines which request should win access to the DRAM.
  • the DIU arbitrates based on configured parameters, to allow sufficient access to DRAM for all requesters.
  • the DIU also hides the implementation specifics of the DRAM such as page size, number of banks, refresh rates etc.
  • the Print Engine Pipeline (PEP) subsystem accepts compressed pages from DRAM and renders them to bi-level dots for a given print line destined for a printhead interface that communicates directly with up to 12 linking printhead ICs.
  • PEP Print Engine Pipeline
  • the first stage of the page expansion pipeline is the CDU, LBD and TE.
  • the CDU expands the JPEG-compressed contone (typically CMYK) layer
  • the LBD expands the compressed bi-level layer (typically K)
  • the TE encodes Netpage tags for later rendering (typically in IR, Y or K ink).
  • the output from the first stage is a set of buffers: the CFU, SFU, and TFU.
  • the CFU and SFU buffers are implemented in DRAM.
  • the second stage is the HCU, which dithers the contone layer, and composites position tags and the bi-level spot0 layer over the resulting bi-level dithered layer.
  • the third stage compensates for dead nozzles in the printhead by color redundancy and error diffusing dead nozzle data into surrounding dots.
  • the resultant bi-level 6 channel dot-data (typically CMYK-IRF) is buffered and written out to a set of line buffers stored in DRAM via the DWU.
  • the dot-data is loaded back from DRAM, and passed to the printhead interface via a dot FIFO.
  • the dot FIFO accepts data from the LLU up to 2 dots per system clock cycle, while the PHI removes data from the FIFO and sends it to the printhead at a maximum rate of 1.5 dots per system clock cycle.
  • some systems have operating parameters that may be governed by a license.
  • the license for use may only authorise a particular print rate.
  • the printing system would ideally be able to access and update the operating parameters in a secure, authenticated way, knowing that the user could not subvert the license agreement.
  • this document defines the QA Chip Logical Interface, which provides authenticated manipulation of a system's operating and consumable parameters.
  • the interface is described in terms of data structures and the functions that manipulate them, together with examples of use. While the descriptions and examples are targeted towards the printer application, they are equally applicable in other domains.
  • the QA Chip Logical Interface is now described.
  • the QA Chip Logical Interface is a logical interface, and is therefore implementation independent. Although this document does not cover implementation details on particular platforms, expected implementations include:
  • An instance of a QA Chip Logical Interface (on any platform) is a QA Device.
  • a System is a logical entity which has one or more QA Devices connected logically (or physically) to it, and calls the functions on those QA Devices.
  • System cannot inherently be trusted i.e. a given QA Device cannot tell if the System is trustworthy or not.
  • System can, however, be constructed within a trustworthy environment (such as a SoPEC or within another physically secure computer system), and in these cases System can trust itself.
  • Digital signatures are used throughout the authentication protocols of the QA Chip Logical Interface.
  • a signature is produced by passing data plus a secret key through a keyed hash function. The signature proves that the data was signed by someone who knew the secret key.
  • the signature function used throughout the QA Chip Logical Interface is HMAC-SHA1.
  • a Trusted QA Device When a System is constructed within a physically/logically secure environment, then System itself is trusted, and any software/hardware running within that secure environment is trusted.
  • a Trusted QA Device is simply a QA Device that resides within the same secure environment that System also resides in, and can therefore be trusted by System. This means that it is not possible for an attacker to subvert the communication between the System and the Trusted QA Device, or to replace the functionality of a QA Device by some other functionality.
  • a Trusted QA Device enables a System to extend trust to external QA Devices.
  • An example of a Trusted QA Device is a body of software inside a digitally signed program.
  • An External untrusted QA Device is a QA Device that resides external to the trusted environment of the system and is therefore untrusted.
  • the purpose of the QA Chip Logical Interface is to allow the external untrusted QA Devices to become effectively trusted. This is accomplished when a Trusted QA Device shares a secret key with the external untrusted QA Device, or with a Translation QA Device (see below).
  • external untrusted QA Devices would typically be instances of SBR4320 implementations located in a consumable or the printer.
  • a Translation QA Device is used to translate signatures between QA Devices and extend effective trust when secret keys are not directly shared between QA Devices.
  • a Consumable QA Device is an external untrusted QA Device located in a consumable. It typically contains details about the consumable, including how much of the consumable remains.
  • the consumable QA Device is typically found in an ink cartridge and is referred to as an Ink QA Device, or simply Ink QA since ink is the most common consumable for printing applications.
  • Ink QA Device or simply Ink QA since ink is the most common consumable for printing applications.
  • other consumables in printing applications include media and impression counts, so consumable QA Device is more generic.
  • An Operating Parameter QA Device is an external untrusted device located within the infrastructure of a product, and contains at least some of the operating parameters of the application. Unlike the Trusted QA Device, an Operating Parameter QA Device is in a physically/logically untrusted section of the overall hardware/software.
  • An example of an Operating Parameter QA Device in a SoPEC-based printer system is the PrinterQA Device (or simply PrinterQA), that contains the operating parameters of the printer.
  • the PrinterQA contains OEM and printer model information that indirectly specifies the non-upgradeable operating parameters of the printer, and also contains the upgradeable operating parameters themselves.
  • a Value Upgrader QA Device contains the necessary functions to allow a system to write an initial value (e.g. an ink amount) into another QA Device, typically a consumable QA Device. It also allows a system to refill/replenish a value in a consumable QA Device after use.
  • an initial value e.g. an ink amount
  • An example of a value upgrader is an Ink Refill QA Device, which is used to fill/refill ink amount in an Ink QA Device.
  • a Parameter Upgrader QA Device contains the necessary functions to allow a system to write an initial parameter value (e.g. a print speed) into another QA Device, e.g. an Operating Parameter QA Device. It also allows a system to change that parameter value at some later date.
  • an initial parameter value e.g. a print speed
  • another QA Device e.g. an Operating Parameter QA Device. It also allows a system to change that parameter value at some later date.
  • a parameter upgrader QA Device is able to perform a fixed number of upgrades, and this number is effectively a consumable value. Thus the number of available upgrades decreases by 1 with each upgrade, and can be replenished by a value upgrader QA Device.
  • Secret transport keys are inserted into QA Devices during instantiation (e.g. manufacture). These keys must be replaced by the final secret keys when the purpose of the QA Device is known.
  • the Key Replacement QA Device implements all necessary functions for replacing keys in other QA Devices.
  • An Authenticated Read is a read of data from a non-trusted QA Device that also includes a check of the signature.
  • the System determines that the signature is correct for the returned data (e.g. by asking a Trusted QA Device to test the signature) then the System is able to determine that the data has not been tampered en route from the read, and was actually stored on the non-trusted QA Device.
  • An authenticated write is a write to the data storage area in a QA Device where the write request includes both the new data and a signature.
  • the signature is based on a key that has write access permission to the region of data in the QA Device, and proves to the receiving QA Device that the writer has the authority to perform the write.
  • a Value Upgrader Refilling Device is able to authorize a system to perform an authenticated write to upgrade a Consumable QA Device (e.g. to increase the amount of ink in an Ink QA Device).
  • the QA Device that receives the write request checks that the signature matches the data (so that it hasn't been tampered with en route) and also that the signature is based on the correct authorization key.
  • An authenticated write can be followed by an authenticated read to ensure (from the system's point of view) that the write was successful.
  • a non-authenticated write is a write to the data storage area in a QA Device where the write request includes only the new data (and no signature). This kind of write is used when the system wants to update areas of the QA Device that have no access-protection.
  • the QA Device verifies that the destination of the write request has access permissions that permit anyone to write to it. If access is permitted, the QA Device simply performs the write as requested.
  • a non-authenticated write can be followed by an authenticated read to ensure (from the system's point of view) that the write was successful.
  • Authorized modification of data refers to modification of data via authenticated writes.
  • the primary purpose of a QA Device is to securely hold application-specific data. For example if the QA Device is a Consumable QA Device for a printing application it may store ink characteristics and the amount of ink remaining.
  • each QA Device must be capable of storing multiple data elements, where each data element is capable of being manipulated in a different way to represent the intended use of that data element.
  • a data element is referred to as a field.
  • Each QA Device requires an identifier that allows unique identification of that QA Device by external systems, ensures that messages are received by the correct QA Device, and ensures that the same device can be used across multiple transactions.
  • the identifier only needs to be unique within the context of a key, since QA Devices only accept messages that are appropriately signed. However it is more convenient to have the instance identifier completely unique, as is the case with this design.
  • a Trusted QA Device In certain circumstances it is useful for a Trusted QA Device to assume the instance identifier of an external untrusted QA Device in order to build a local trusted form of the external QA Device. It is the responsibility of the System to ensure that the correct device is used for particular messages.
  • a Trusted QA Device in a SoPEC-based printing system has the same instance identifier as the external (untrusted) Printer QA so that the System can access functionality in the Trusted QA instead of the external untrusted Printer QA.
  • the identifier functionality is provided by ChipId.
  • ChipId is the unique 64-bit QA Device identifier. The ChipId is set when the QA Device is instantiated, and cannot be changed during the lifetime of the QA Device.
  • a 64-bit ChipId gives a maximum of 1844674 trillion unique QA Devices.
  • Each QA Device contains a number of secret keys that are used for signature generation and verification. These keys serve three basic functions:
  • signature generation a key is used to generate a signature for subsequent transmission from the device, and to generate a signature to compare against a received signature.
  • the transportation function is additionally achieved by encryption.
  • the number of secret keys in a QA Device is given by NumKeys, and has a maximum value of 256, i.e. the number of keys for a particular implementation may be less than this.
  • NumKeys a QA Device
  • each keyslot contains a single key.
  • the nth keyslot contains the nth key (where n has the range 0 to NumKeys-1).
  • the keyslot concept is useful because a keyslot contains not only the bit-pattern of the secret key, but also additional information related to the secret key and its use within the QA Device.
  • the term Keyslot[n].xxx is used to describe the element named xxx within Keyslot n.
  • K Keyslot[n].K.
  • each key is 160 bits. 160 bits was chosen because the output signature length from the signature generation function (HMAC-SHA1) is 160 bits, and a key longer than 160-bits does not add to the security of the function.
  • keys should be generated in a way that is not deterministic. Ideally the bit pattern representing a particular key should be a physically generated random number, gathered from a physically random phenomenon. Each key is initially programmed during QA Device instantiation.
  • each key has a corresponding 18-bit KeyId which can be read to determine the identity or label of the key without revealing the value of the key itself. Since the relationship between keys and KeyIds is 1:1 (they are both stored in the same keyslot), a system can read all the KeyIds from a QA Device and know what key is stored in each of the keyslots.
  • the bit pattern for such a key should be set to a random bit pattern for the physical security of any other keys present in the QA Device.
  • SIG key dependent one-way hash function
  • HMAC-SHA1 HMAC-SHA1
  • Signatures are only of use if they can be validated i.e. QA Device A produces a signature for data and QA Device B can check if the signature is valid for that particular data. This implies that A and B must share some secret information so that they can generate equivalent signatures.
  • a one-way function is required to create K A from K B or it would be possible to derive K B if K A were exposed.
  • A can produce SIG KA (message), but for B to produce an equivalent signature B must produce K A by being told U A from A and using B's base key K B .
  • K A is referred to as a variant key and K B is referred to as the base key. Therefore, B can produce equivalent signatures from many QA Devices, each of which has its own unique variant of K B . Since ChipId is unique to a given QA Device, we conveniently use that as U A .
  • Common key signature generation is used when A and B are effectively equally available 1 to an attacker. Variant key signature generation is used when B is not readily available to an attacker, and A is readily available to an attacker. If an attacker is able to determine K A , they do not know K A for any other QA Device of class A, and they are not able to determine K B . 1
  • the term “equally available” is relative. It typically means that the ease of availability of both are the effectively the same, regardless of price (e.g. both A and B are commercially available and effectively equally easy to come by).
  • U A is ChipId
  • their variant keys can be effectively treated as common keys for signatures passed between them, but as variant keys when passed to other devices.
  • the QA Device producing or testing a signature needs to know if it must use the common or variant means of signature generation. Likewise, when a key is stored in a QA Device, the status of the key (whether it is a base or variant key) must be stored in the keyslot along with the key for future reference.
  • each keyslot contains a 1-bit Variant flag to hold the status of the key in that keyslot:
  • the QA Device itself doesn't directly use the Variant setting. Instead, the System reads the value of variant from the desired keyslots in the two QA Devices (one QA Device will produce the signature, the other will check the signature) and informs the signature generation function and signature checking functions whether or not to use base or variant signature generation for a particular operation.
  • a compromise of a single key means a compromise of all keys.
  • the reason is that the compromised key can be used by an attacker to transport all other keys out of a QA Device.
  • Some QA Devices (such as Key Replacement QA Devices) are specifically required to transport keys, while others (such as those devices used in consumables) should not ever transport their keys out.
  • a key may be a transport key when stored in QA Device A, and although we want to store that same key in a Key Replacement QA Device B for future injection into A, we do not want that key to be used to transport keys from B.
  • a key is not in its final intended keyslot, then it should have no abilities in that QA Device other than being transported out, and the intended use of the key (for example whether or not it will be a transport key when installed in its final destination) needs to be associated with that key.
  • each keyslot contains 3 ⁇ 1-bit flags as follows:
  • a freshly manufactured QA Device A will most likely have the 3 bits for each keyslot set to 000 so that all the keys are replaceable.
  • key replacement QA Device B To replace one of A's keys (k1) by another batch key (k2), key replacement QA Device B is required where B typically contains k1 with 3 bits set to 001, and k2 with 3 bits set to 010. After k2 has been transferred into A, the 3 bits within A will be now set to 000. Thus k2 cannot be used or replaced within B, but can be replaced within A.
  • key replacement QA Device B To replace one of A's keys (k1) by a final use data key (k2), key replacement QA Device B is required where B typically contains k1 with 3 bits set to 001, and k2 with 3 bits set to 110. After k2 has been transferred into A, the 3 bits within A will be now set to 101. Thus k2 can be used within A but not B, and cannot be transported out of A.
  • KeyNum keyslots in a QA Device, not all keyslots may be required for a given application. For example, a QA Device may supply 256 keyslots, but only 2 keys may be required for a particular application. The remaining keyslots need to be invalidated so they cannot be used as a reference for signature checking or signature generation.
  • QA Device A When QA Device A has a keyslot with KeyType, TransportOut, and UseLocally set to 000, then the key in that keyslot can be replaced.
  • key replacement QA Device B is required where B typically contains:
  • k2 After k2 has been transferred into A as a variant key, the 3 bits within A will be now set to 100. Thus k2 cannot be used within A, cannot be transported out of A, and cannot be replaced. Moreover, being a variant key in A, k2 will be different for each instance of A and will therefore be contribute to the entropy of A. Any system reading the KeyIds that are present in A will see that the keyslot contains a key whose keyId is 0 (and is therefore invalid) and whose 2-bits specify that the key cannot be used.
  • a special command could be available in each QA Device to allow the caller to transform the KeyType, TransportOut, and UseLocally settings for a keyslot from some value to 100.
  • the key in that slot would then be non-transportable non-usable, and therefore invalid.
  • each keyslot contains a 4-bit boolean (which should be nybble-aligned within the keyslot data structure) referred to as Invalid, where 0000 represents a valid key in the keyslot, and non-zero represents an invalid key.
  • Invalid a 4-bit boolean (which should be nybble-aligned within the keyslot data structure) referred to as Invalid, where 0000 represents a valid key in the keyslot, and non-zero represents an invalid key.
  • a specific command exists in the QA Logical Interface to allow a caller to invalidate a previously valid key.
  • each QA Device contains a number of data elements (each element referred to as a field), each of which can be operated upon by one or more keys.
  • a field data elements
  • keys and fields it is useful to have a set of permissions for each key on each field.
  • key 1 may have read-only permissions on field 1, but read/write permissions on field 2 and read/decrement-only permissions on field 3.
  • the scheme must cope with multiple keys having the same permissions for a field to support the following situations:
  • each of the various users of the QA Device has access to a different key, such that different users can be individually included or excluded from access
  • keygroup 1 contains a number of keys, and each field has a set of permissions with respect to the keygroups.
  • keygroup 1 (containing some number of keys) may have read-only permissions on field 1, but read/write permissions on field 2 and read/decrement-only permissions on field 3.
  • the storage requirements for the permissions on each field would be the same as the general case without keygroups, but by limiting the number of keygroups, the storage requirements for the permissions on each field can be pre-known, constant, and is decoupled from the actual number of keys in the device.
  • the number of keygroups in a QA Device is 4. This allows for 2 different keygroups that can transfer value into the QA Device, and for 2 different keygroups that can transfer value out of a QA Device, where each of the 4 keygroups is independent of the others. Note that transport keys do not need to be allocated a keygroup since they cannot be used to authorise reads or writes of data.
  • each keyslot contains a 2-bit KeyGroup identifier.
  • a stamp franking system may contain value in the form of ink plus a dollar amount.
  • the keys and fields relating to ink may be injected at one physical location, while the keys and fields relating to dollars may be injected at a separate location some time later.
  • boolean indicator that indicates whether a particular keygroup is locked. Once a keygroup is locked, then no more keys can be added to that keygroup.
  • the boolean indicator is accessible per keyslot rather than as a single indicator for each keygroup in order that someone reading the keyslot information can know:
  • the keygroup for that key can be locked at the same time. This will cause the QA Device to change the status of all keys with the same KeyGroup value from keygroup-unlocked to keygroup-locked, thereby preventing the addition of any more keys in the keygroup.
  • each keyslot contains a 4-bit boolean (which should be nybble-aligned within the keyslot data structure) referred to as KeyGroupLocked, where 0000 represents that the keygroup to which the key in the keyslot belongs is unlocked (i.e. more keys can be added to the keygroup), and non-zero represents that the keygroup to which the key in the keyslot belongs is locked (i.e. more keys cannot be added to the keygroup).
  • KeyGroupLocked 4-bit boolean (which should be nybble-aligned within the keyslot data structure) referred to as KeyGroupLocked, where 0000 represents that the keygroup to which the key in the keyslot belongs is unlocked (i.e. more keys can be added to the keygroup), and non-zero represents that the keygroup to which the key in the keyslot belongs is locked (i.e. more keys cannot be added to the keygroup).
  • a Key Replacement QA Device does not need to check whether or not there are fields on the target device with write permissions related to a particular keygroup. The reason is that the target QA Device only allows field creation related to a keygroup if the keygroup is locked. Therefore if there was such a field in the target device one of the following is true:
  • the target QA Device is a fake one created by an attacker. If so, and if the attacker does not know the original key, then the replaced key will be of no value. If the attacker does know the original key, then they can determine the replacement key (since the replacement key is encrypted using the original key for transport) without creating a fake QA, and can therefore generate fake value as desired.
  • the target QA Device has come under physical attack (it's a real QA Device). If an attacker can do this, it's easier to allow the key replacement first, and then create a fake field. This situation cannot ever be detected by the Key Replacement QA Device.
  • two QA Devices A and B are required such that A and B are intended to work together via a conceptual key k. While a single key could be used for k, it is more secure to limit the lifetime of any particular key, and to have a plan in place to remove a key from use should it be compromised.
  • Rolling keys are where multiple keys are stored in at least one of A and B such that different keys can be used at different times during the life of A and B, different instances of A and B at differing manufacture times can be programmed with different keys yet still work together, and keys can be retired from use in A and/or B.
  • a rolling key example system for this example is where A contains multiple keys k 1 , k 2 . . . k n , each with a different KeyId, where each of these keys has the same permissions on datafields within A (typically they will all belong to the same keygroup in A).
  • B contains a single key k 1 (that is also present in A). For a given time period k 1 can be used between A and B.
  • Bs are manufactured only containing k 2 , and new As are manufactured only containing k 2 , k 3 . . . k n , k n+1 .
  • Bs are manufactured only containing k 3 and new As are manufactured only containing k 3 , k 4 . . . k n , k n+1 , k n+2 etc.
  • B may be an ink cartridge that has a use-by date of 12 months while A is a printer that must last for 5 years:
  • A can have 1 set of rolling keys with B, and can have a different set of rolling keys with C. This requires 1 key in B, 1 key in C, and two sets of multiple keys in A.
  • the rolling key structure can be extended to work with value hierarchy.
  • A uses value from B, and value in B is replenished by C, then A and B can have one set of rolling keys, and B and C can have a different set of rolling keys and each set of rolling keys can roll at different times and rates.
  • a and B can have one set of rolling keys
  • B and C can have a different set of rolling keys and each set of rolling keys can roll at different times and rates.
  • each of the keys in a set of rolling keys has exactly the same purpose as the others in the set, and is used in the same way in the same QA Devices, but at different times in a product's life span.
  • Each of the keys has a different KeyId.
  • a set of rolling keys is held in a QA Device, they all belong to the same keygroup.
  • the variant/base form of rolling keys When the variant/base form of rolling keys is used, at any given time, only one base key is injected during manufacture. This is the current manufactured instance of the rolling key. Several of the key instances can be used in manufacture, in their variant forms. One by one, the current manufactured instance of the rolling key is replaced by subsequent instances of the rolling key.
  • a particular current manufactured instance of a key is replaced by the next instance in the rolling key set in all of the QA Devices where it is used.
  • Rolling key instances which are before the first valid instance are considered to be invalid, and they should be invalidated in any manufactured product in the field whenever they are found.
  • the question is how to enforce the eradication process, especially if the QA Devices are not in direct contact with a central authority of some kind.
  • the QA Logical Interface allows a particular key in a keyslot to be invalidated.
  • An external entity needs to know which keys are invalid (for example by knowing the invalid keys' KeyIds). Assuming that the entity can read the KeyIds present in a QA Device the entity can invalidate the appropriate keys in the QA Device. The entity could refuse to operate on a QA Device until the appropriate keys have been invalidated.
  • a printer system has an ink cartridge and a refill cartridge.
  • the printer system uses rolling key set 1 to communicate with the ink cartridge, and the ink cartridge is refilled from the refill cartridge via rolling key set 2.
  • the refill cartridge contains a specific field containing an invalid key list.
  • the system software in the printer knows that this field contains an invalid key list, and refuses to transfer the ink value from the refill cartridge to the ink cartridge until it has invalidated the appropriate keys on the ink cartridge.
  • every time the system software for the printer is delivered/updated to the printer (e.g. downloaded off the internet), it can contain a list of known invalid keys and can apply these to anything it is connected to, including ink cartridges and refill cartridges.
  • the value server can invalidate the appropriate keys on the QA Device before injection of value. Done correctly, the invalid keys will be deleted from use in all valid systems, thereby reducing the effect of a clone product.
  • MostRecentValidatedDate can be obtained locally. Otherwise the MostRecentValidatedDate can only be obtained when the system comes into contact with another trusted component.
  • the trusted component could be software that runs on system, with a particular build date (and this date is therefore trusted), or a date stored on a QA Device (providing the date is read from the QA Device via keys and can only be set by a trusted source).
  • At least one of the QA Devices in systems that support rolling keys should define at least two fields for the purposes of key invalidation: a field that contains the invalid key list (a list of invalid keyIds), and a field that contains a date that can contribute to a MostRecentValidatedDate.
  • the Logical QA Interface currently supports a field type specifically for the former (see Appendix B), while the latter depends on the specifics of a particular application.
  • the 18-bit KeyId could be composed of a 10-bit RollingKeySetId, and an 8-bit RollingKeyInstance.
  • each set of rolling keys would have 256 unique key values to be used in the sequence.
  • a configuration that consists of a system A that communicates with a QA Device B.
  • a printer system that communicates with an Operating Parameter QA Device (e.g. containing the print speed).
  • the system reads the print speed before printing a page.
  • B has physical security since it is a QA Device, and A does not have such high security, then it is desirable to store the variant form of the key in A and the base form of the key in B. If the key is extracted from A (having less security than B), then at least other systems cannot be subverted with clone Bs.
  • a can be programmed with a variant key after B has been attached e.g. A contains non-volatile memory
  • a cannot be programmed after B has been attached such as is the case with the SoPEC ASIC
  • A can now create a Trusted QA Device and communicate with B using A's variant key.
  • C and D include a Consumable QA Device such as an ink cartridge, and a Parameter Upgrader QA Device such as a permanent speed-upgrade dongle.
  • A can hold many keys, i.e. can be programmed with many keys during manufacture, then A can be programmed with appropriate variant keys for C and D using the same scheme as described above for B.
  • QA Devices are passive: commands are issued to them by the System, which is an entity mediating the communications between the QA Devices.
  • the QA Device Protocol lists a set of commands that can be sent to a QA Device, and for each command, there is a set of valid responses.
  • the protocol defines the features that are common to the commands.
  • a command consists of a number of 32-bit words where the first byte of the first word contains a command byte, and subsequent words contain up to four of the following blocks of data:
  • the response to a command consists of a number of 32-bit words, where the first byte of the first word contains a response byte, and subsequent words contain up to two of the following blocks of data:
  • the arrangement of data within each 32-bit word is arranged in big-endian format.
  • the assumption is that the System and the QA Device are processing the commands and responses in big-endian format.
  • the first 32-bit word contains a two-byte length that indicates the block length in 32-bit words, followed by the block data itself.
  • the length is inclusive. Thus the length for a parameter block with no data content is 1.
  • the QA Device identifier ChipId is present in all SignedInputParameterBlock and signed OutputParameterBlock entity lists. This ensures that a signature over the block of data uniquely identifies the QA Device that the list is for or came from. This prevents attacks where commands that are intended for one QA Device are redirected to another, or when responses from one QA Device are passed off as being from another.
  • the list is an incoming modify-entity list or an outgoing read-entity list, then the list ChipId must be the ChipId of the Commanded QA Device. If it is not, then the command fails.
  • the list is an incoming read-entity list or an outgoing modify-entity list
  • the list ChipId is typically the ChipId of some other QA Device.
  • a signed outgoing list of entities being read from a QA Device has a signature over a block of data that includes that QA Device's ChipId. Thus ensures that the data cannot be mistaken for data from another QA Device.
  • a signed incoming list of entities being written to a QA Device has a signature over a block of data that includes that QA Device's ChipId. This ensures that the data cannot be wrongly applied to any other QA Device.
  • a Commanded QA Device accepts a signed Entity List as input, where the Entity List was generated by another QA Device A, and produces a signed Entity List as output where the output is suitable to be subsequently applied to A as an incoming Entity List.
  • commands include: Get Key, Transfer Delta, Transfer Assign, and Start Rollback.
  • Commands in the QA Device command set are distinguished by CommandByte.
  • Table 1 describes the CommanByte values: Values and Interpretation for CommandByte CommandByte Value Description GET INFO 1 Get summary of information from the QA Device GET CHALLENGE 2 Get a nonce from the QA Device.
  • LOCK KEY GROUPS 3 Lock a specified set of keygroups. This prevents any keys in the keygroups from being subsequently replaced.
  • LOCK FIELD 4 Lock all field creation in the QA Device. Locking field creation CREATION prevents any fields from subsequently being created.
  • READ 5 Read a group of key descriptors, field descriptors and/or field values from a QA Device.
  • AUTHENTICATED 6 Read a group of key descriptors, field descriptors and/or field READ values from a QA Device. The results are accompanied by a signature to authenticate the results.
  • AUTHENTICATED 7 Specify a group of key descriptors, field descriptors and/or field READ WITH values in a QA Device, and read the signature over that data.
  • SIGNATURE ONLY WRITE 8 Write a group of field values to fields in the QA Device.
  • AUTHENTICATED 9 Write a group of field values to fields in the QA Device. The WRITE write command is authenticated by a signature over the list of field values.
  • CREATE FIELDS 10 Create a group of fields in a QA Device.
  • REPLACE KEY 11 Replace a key in a QA Device.
  • INVALIDATE KEY 12 Make a key in a QA Device invalid.
  • GETKEY 13 Get an encrypted key from a QA Device.
  • TEST 14 Request a QA Device to test the signature over an arbitrary block of data.
  • SIGN 15 Request a QA Device to create a signature over an arbitrary block of data.
  • TRANSFER DELTA 16 Request a QA Device to transfer some value from it to another QA Device where the value is correspondingly reduced in the Commanded QA Device).
  • TRANSFER ASSIGN 17 Request a QA Device to transfer an assignment of value to another QA Device . . . START ROLLBACK 18 Request a QA Device to begin rollback proceedings to ensure that a previously transferred value has not and can never be used.
  • ROLLBACK 19 Request a QA Device to undo a previously requested transfer of value to another QA Device.
  • the ResultFlag is a byte that indicates the return status from a function. Callers can use the value of ResultFlag to determine whether a call to a function succeeded or failed, and if the call failed, the specific error condition.
  • Table 2 describes the ResultFlag values and the mnemonics used in the pseudocode ResultFlag value description Mnemonic Value Description Pass 0 Function completed successfully. Function successfully completed requested task. Fail 1 General failure. An error occurred during function processing.
  • QA NotPresent 2 QA Device is not contactable Invalid Command 3 The QA Device does not support the command Bad Signature 4 Signature mismatch. The input signature didn't match the generated signature.
  • Invalid Key 5 Invalid keyslot number. The keyslot specified is greater than the number of keyslots supported in the QA Device, or the key in the specified keyslot is invalid.
  • Invalid Key Type 6 The key in the requested keyslot is the wrong type for the particular operation.
  • a TransportKey was requested for a data-based signature, or a DataKey was requested for a key-based signature.
  • Key Number Out 7 A key was specified for a signature which had a key slot Of Range number out of range Key Not Locked 8 A command was received, authenticated by an unlocked key. Unlocked keys may not be used to authenticate any operations, with the exception of the transport of keys, to authenticate and encrypt new key values.
  • a OutputSignatureGenerationBlock was not received in a Generation Block command which requires an outgoing signature Absent Signature 10
  • a OutputSignatureGenerationBlock was received in a Generation Block command which does not require an outgoing signature Wrongly Present Signature Block 11
  • a InputSignatureCheckingBlock was not received in a Absent command which requires an incoming signature Signature Block 12
  • a InputSignatureCheckingBlock was received in a Wrongly Present command which does not require an incoming signature Parameter Block 13
  • An Input Parameter Block wasn't received in a command Absent which requires that block, or an Output Parameter Block was not generated by a command which requires one.
  • An Input Parameter Block was received in a command Wrongly Present which does not require that block, or an Output Parameter Block was generated in a command that does not require one. Too Many 15
  • the Input Parameter Block of the command has a list of Entities more entities than the QA Device supports Too Few Entities 16
  • An Entity List or an Entity Descriptor List was received in a command or sent in a response with no entities.
  • Illegal Entity 18 An entity descriptor in an input or output parameter block Descriptor list was set wrongly: it was “modify” when it needed to be Modify Bit “read”, or “read” when it needed to be “modify”.
  • the QA Device was given a command which had a SignedInputParameterBlock with modify-entities, or generated a signed OutputParameterBlock with read- entities, and the ChipId in the signed block was incorrect, i.e. not the ChipId of the QA Device.
  • Illegal Entity 20 An entity in an Input Parameter Block of a command was received that is not legal for that command.
  • No Shared Key 21 An operation was requested in a command to a QA Device which requires a key to be shared between it and another QA Device. If there is no shared key, this error is returned.
  • Invalid Write 22 Permission not adequate to perform operation. For example, Permission trying to perform a Write or WriteAuth with incorrect permissions.
  • Field Creation 29 Field creation was attempted in this QA Device, after it has Not Allowed been locked or there was an attempt to lock field creation after it had been already locked.
  • Field Storage 30 The QA Device is out of storage space for new fields.
  • Overflow Type Mismatch 31 Type of the data from which the amount is being transferred in the Upgrading QA Device, doesn't match the Type of data to which the amount in being transferred in the Device being upgraded.
  • Transfer Dest 32 A transfer was attempted on a field which is not capable of Field Invalid supporting a transfer.
  • Rollback Enable 33 The rollback enable field for the QA Device being Field Invalid transferred to is invalid. No Transfer 34 There is no transfer source field available to do the transfer Source Field from. Transfer Source 35 The transfer source field doesn't have the amount required Field Amount for the transfer.
  • Insufficient Invalid Operand 36 One of the command operands was invalid.
  • Field Over 37 A Write or an Authenticated Write command was applied to Maximum a field which would have made the field value exceed the Allowed limit implied by its “maximum allowed” bit field.
  • Transfer Fields 38 The “who I am” and “who I accept” fields in the transfer Incompatible source and transfer destination fields are not compatible.
  • Transfer Rolled 39 A transfer was attempted which failed. The transfer was Back successfully rolled back, so the source and transfer fields are unchanged. No Matching 40 A Rollback was attempted on a QA Device which had no Previous Transfer record of having done a corresponding transfer (loss of previous record may occur depending on the depth of the rollback cache Key Not For 41 An operation was requested using a data key for which local Local Use use is not permitted.
  • the GetInfo function tells the caller what kind of QA Device this is, what functions are available and what properties this QA Device has. The caller can use this information to correctly call functions with appropriately formatted parameters.
  • Source code control identifier tells the caller which software version the QA Device has. There must be a unique mapping of the source code control identifier to a body of source code, under source code control, in any released QA Device.
  • Additional information may be returned depending on the type of QA Device.
  • the additional data fields of the output hold this additional information.
  • Table 3 describes each of the output parameters. Description of output parameters for GetInfo function Parameter #bytes Description ResultFlag 1 Indicates whether the function completed successfully or not. If it did not complete successfully, the reason for the failure is returned here.
  • QA Device type 1 This defines the function set that is available on this QA Device.
  • Source Code 4 This uniquely defines the source code for the QA Device, as Control Identifier controlled by a source code control system. Key Replacement 1 Bit mask of keygroups which are not locked. Key replacement Allowed is allowed to add keys to those keysgroups.
  • Table 4 shows the mapping of QA Device Type: QA Device Types QADevice Type ⁇ Description 1 Base QA Device 2 Value Upgrader QA Device 3 Parameter Upgrader QA Device 4 Key Replacement QA Device 5 Trusted QA Device
  • Table 5 shows the mapping between the QA Device type and the available device functions on that QA Device. Mapping between QA Device Type and available device functions Supported on QA Device Device QA Device Function Types description Get Info all Base QA Device Get Challenge Lock Key Groups Lock Field Creation Authenticated Read Authenticated Write Non-authenticated Write Create Fields Replace Key Invalidate Key Transfer Delta 2 Value Upgrader Start Rollback QA Device Roll Back Amount (e.g. Ink Refill QA Device) Transfer Amount 3 Parameter Upgrader Start Rollback QA Device Rollback Field (e.g. Local Upgrader QA Device) GetKey 4 Key Replacement QA Device Sign 5 Trusted Device Test
  • Table 6 shows the VarData components for Value Upgrader and Parameter Upgrader QA Devices.
  • VarData for Value and Parameter Upgrader QA Devices Length VarData in Components bytes Description DepthOfRollBackCache 1 The number of data sets that can be accommodated in the Xfer Entry cache of the device.
  • An Authenticated Transfer is the process where a store of value is securely transferred from one QA Device to another.
  • a Rollback is where a previous attempted transfer is annulled, when the transferring QA Device is given evidence that the transfer never succeeded, and can never succeed in the future.
  • the QA Device from which the value is being transferred is called the Source QA Device, and the QA Device to which the value is being transferred is called the Destination QA Device.
  • the stores of values can be either consumables, or properties.
  • consumables are things like picolitres of ink, millimetres of paper, page impressions etc. They are things that are consumed as the printing process is taking place.
  • properties are things like printer features, such as the right to print at a certain number of pages per second, or the right to interwork with a certain bit of equipment, such as a larger ink cartridge, (which may be cheaper to buy per litre of ink).
  • a property can also be a printer license, which has an implied printer feature set. That is, if a printer has a license, it has a certain feature set, and other non-selectable printer features have certain default values.
  • Properties are things which are not consumed as the printing takes place, but which can be assigned to a printer and which remain as attributes of that printer.
  • Fields in QA Devices have a transfer mode, which can be one of:
  • the flow of virtual consumables is from QACo, via the OEM factories, to the consumable containers, such as ink cartridges in the home or office.
  • the virtual consumables are created ex nihil in QACo, transferred without being created or destroyed to the home or office, and then consumed.
  • virtual consumables are assigned to a consumable container to be used in SOHO, it should be done in tandem with physically filling the container, so that the two are in agreement.
  • the flow of properties is from QACo, via the OEM factories or OEM internet resellers, to printers and dongles, for use in the home and office.
  • the properties are stored as quantities of properties until they get to their final destination, where they are assigned as single properties.
  • the transfer process has two basic requirements:
  • the transfer and rollback process is shown in FIG. 28 .
  • the System makes a Start RollBack request to the Source QA Device with same input parameters as the Transfer, and the output from Read in (4).
  • the Source QA Device validates the Start RollBack Request based on the Read output, and then produces the necessary Start Rollback output.
  • the Start Rollback output consists only of additional field data along with a signature.
  • Both rollback enable fields are decrement-only fields, initialised to 0xFFFFFFFF when they are created, and they can only be decreased via authenticated writes.
  • the authenticated read contains the field descriptors and field values for the rollback enable fields.
  • the transfer source QA Device checks that they are present, and remembers their values.
  • the authenticated write for the transfer includes:
  • the transfer source QA Device If a rollback is requested, then the transfer source QA Device generates the arguments for an authenticated write to the transfer destination which include:
  • the pattern of “rollback enable value ⁇ 1” and “rollback enable value ⁇ 2” means that only one of the authenticated writes can be applied, not both. If the Transfer write has succeeded, then the Rollback write can never be applied, and if the Rollback write has succeeded, then the Transfer write can never be applied.
  • the basic authorisation for a transfer comes from a key that has authenticated ReadWrite permission (stored in field information as KeyNum) to the destination fields in the Destination QA Device. This key is referred to as the transfer key.
  • the Source QA Device After validating the input transfer request, the Source QA Device decrements the amount to be transferred from its source field, and produces the arguments for an authenticated write, and a signature using the transfer key.
  • the signature produced by the Source QA Device is subsequently applied to the Destination QA Device.
  • the Destination QA Device accepts the transfer amount only if the signature is valid. Note that the signature is only valid if it was produced using the transfer key which has write permission to the destination field being written.
  • the Source QA Device validates the transfer request by matching the Type of the data in the destination field of Destination QA Device to the Type of data in the source field of the Source QA Device. This ensures that equivalent data Types are transferred e.g. a quantity of type Network_OEM1_infrared ink is not transferred into a field of type Network_OEM1_cyan ink.
  • the compatibility word consists of two 16-bit fields, called “who I am” and “who I accept”. For the transfer to take place, each side must accept the other. That is expressed in this way: if (the source “who I am” bitwise-ANDed with the destination “who I accept” is non-zero) AND (the destination “who I am” bitwise-ANDed with the source “who I accept” is non-zero) are both non-zero, then the transfer can take place, otherwise it can't.
  • the source field's “upgrade to/from” word is used as follows:
  • the Authenticated Write arguments should have these values:
  • the arguments of the Authenticated Write should have the “write/add” bit in the entity descriptors set to “add”, for the rollback enables, and the field value in the Transfer Delta case. It should be set to “write” for the field value in the Transfer Assign case.
  • the use of the “add” option in the Authenticated Write eliminates a class of race conditions.
  • the Transfer Delta function is to transfer value, the value being a quantity of consumables or a quantity of properties. This distinction (compared to a Transfer Assign) is above.
  • the system calls the Transfer Delta function on the upgrade device with a certain Delta. This Delta is validated by the Transfer Delta function for various rules, the function then produces the data and signature for the passing into the Authenticated Write function for the device being upgraded.
  • the Transfer Delta output consists of the new data for the field being upgraded, field data of the two rollback enable fields, and a signature using the transfer key.
  • Non-volatile memory is memory that retains its state after power is removed.
  • flash memory is a form of non-volatile memory.
  • flash memory and non-volatile memory are used interchangeably in the detailed description.
  • a bit can either be in its erased state or in its programmed state. These states are referred to as E and P.
  • E may be 0 or 1
  • P is the inverse of E.
  • a FIB Fracused Ion Beam
  • a FIB can be used to change chosen bits of flash memory from E to P, or from P to E.
  • a FIB may be used to set a bit from an unknown state to a known state, where the known state depends on the flash memory technology.
  • An integrated circuit may be manufactured with flash memory, and may contain an embedded processor for running application program code.
  • XOR is the bitwise exclusive-or function. The symbol is used for XOR in equations.
  • K is an integer (typically large) that is used to digitally sign messages or encrypt secrets.
  • K is N bits long, and the bits of K are referred to as K 0 to K N ⁇ 1 , or K i , where i may run from 0 to N ⁇ 1.
  • the Binary Inverse of a Key is referred to as ⁇ K.
  • the bits of ⁇ K are referred to as ⁇ K i , where i may run from 0 to N ⁇ 1.
  • R A Random Number used for the purposes of hiding the value of a key when stored in non-volatile memory is referred to as R.
  • the bits of R are referred to as R i , where i may run from 0 to N ⁇ 1.
  • a function of a key K is stored in non-volatile memory, it is referred to as X.
  • the bits of X are referred to as X i , where i may run from 0 to N ⁇ 1.
  • the same key is stored in multiple ICs, all available to an attacker.
  • the IC may be manufactured into a consumable and the consumable is sold to the mass market.
  • the problem is to ensure that the secret key remains secret, against a variety of attacks.
  • FIB Fluorescence Ion Beam
  • the FIB attack is a write-only attack—the attacker modifies flash memory and tests for changes of the chip behaviour.
  • a series of FIB attacks allows the attacker to obtain the entire key. At most, an attacker requires N chips to obtain all N bits, but on average only N/2 chips are required.
  • the program in flash memory checks that the value read from the first location is the binary inverse of the value stored in the second location, before K is used, and the program fails if it is not, then an attacker cannot use the behaviour of the chip to determine whether a single bit attack hit a bit of K or ⁇ K.
  • the chip is subject to an attacker performing multiple-bit FIB attacks, assuming that the attacker knows the two locations where K and ⁇ K are stored, but does not know which location contains K; and that the program in the chip checks that the values stored at the two locations are inverses of each other, and fails if they are not.
  • the attacker chooses a positive integer T.
  • X, ⁇ X and R are stored in memory randomly with respect to each other, and the program that accesses the key also needs to know the placement. Thus, for a randomly selected chip it is not clear to an attacker whether a bit at a particular location belongs to X, ⁇ X or R.
  • K still susceptible to attack, by an attacker performing FIB attacks on pairs of bit pairs.
  • the chip is programmed with X, ⁇ X and R, and they are in known locations, but it is not known by the attacker what order they are in; and that the program in the chip checks that stored value for X is indeed the binary inverse of the stored value for ⁇ X, and fails if it is not.
  • the program insertion re-links the program every time a chip is programmed, then the key and key-related information can be placed in an arbitrary random places in memory, on a per-chip basis. For any given chip, the attacker will not know where the key could be.
  • failures where the program either reports an incorrect key value, or it is clear that the key value is incorrect, because it is unable to encrypt
  • failures where the program either reports an incorrect key value, or it is clear that the key value is incorrect, because it is unable to encrypt
  • other kinds of failures If the program becomes unable to do key-related functions (encrypt, decrypt, digitally sign or check digital signatures, etc), but is otherwise functioning well, then the attacker can deduce that the most recent attack probably hit some key-related information.
  • the attacker After T attempts, the attacker has a record of how many hits H i were recorded for bit i in the key.
  • T To launch this attack, an attacker requires T ⁇ N chips. Note that for the experiments to be useful, T needs to be large enough to launch an attack on M.
  • This method of storing a key is not considered secure, because it is difficult, though not impossible, for an attacker to use an FIB to retrieve the key.
  • K and ⁇ K are each placed into a random location in flash memory such that the possible locations for storage do not overlap with each other, and that the program in the chip checks that the stored values at the two locations are inverses of one another and fails if it is not, then an attacker can extract the key.
  • T To launch this attack, an attacker requires T ⁇ N chips. Note that for the experiments to be useful, T needs to be large enough to launch an attack on M.
  • the keys will be held in memory in units of a particular word size, and those words will be held in an array of words, aligned with the word size. So, for example, a particular key might be 512 bits long, and held in an array of 32-bit words, and the words are aligned in flash memory at 32-bit boundaries. Similarly, another system might have a key that is 160 bits long, held in an array of bytes, aligned on byte boundaries.
  • a key is N bits long, aligned with a word-size of W, and placed in flash memory starting at an arbitrary word address, then there will be N/W bits that are aliased together from the point of view of the attacker. This is called the aliased bit group. This is because an attack on bit x in flash could be a hit to K i , K i+W , K i+2W , etc, depending on which word in memory the key started.
  • a particular key is 512 bits long, and is held in an array of 32-bit words, then there are 16 elements (512/32) in each aliased bit group.
  • another system's key is 160 bits long, held in an array of bytes, then there are 20 elements (160/8) in each aliased bit group.
  • failures where the program becomes unable to use its key
  • failures where the program becomes unable to use its key
  • other kinds of failures If the program becomes unable to do key-related functions (encrypt, decrypt, digitally sign or check digital signatures, etc), but is otherwise functioning well, then the attacker can deduce that the most recent attack hit some key-related information.
  • the key K is placed into a random location in flash memory for each chip, then an attacker can extract the key.
  • the attacker has W fractions H i /T, one for every bit in the flash memory's words.
  • B i is the number of bits in the aliased bit group that are E in the key.
  • k ⁇ B i is the number of bits in the aliased bit group that are P in the key. So the attacker knows to within a permutation what the key bit values are.
  • T To launch this attack, an attacker requires T ⁇ W chips. Note that for the experiments to be useful, T needs to be large enough to launch an attack on M.
  • K and ⁇ K are each placed into one of two random locations in flash memory for each chip, and the program checks that the stored values in both locations are binary inverses of each other and fails if they are not, then an attacker can extract the key.
  • the attacker has W ⁇ 1 fractions H i /T, one for each bit 1 -W ⁇ 1 in the flash memory's words.
  • keys When keys are stored in flash, the key bits can be guarded by an increasingly elaborate set of operations to confound attackers. Examples of such operations include the XORing of key bits with random numbers, the storing of inverted keys, the random positioning of keys in flash memory, and so on.
  • the basic problem of the storing and checking of keys is that the bits of the key-related entities ( ⁇ K, R, etc) can be directly correlated to the bits of the key.
  • a method of solving the problem is to guard the key bits using a value that has no correlation with the key bits as follows:
  • the one-way function should have the property that if there is any bit difference in the function input, there are on average differences in about half of the function output bits. SHA1 has this property.
  • a chip may need to hold multiple keys in flash memory. For this discussion it is assumed that a chip holds NumKeys keys, named K[0]-K[NumKeys ⁇ 1]
  • the attack relies on the fact that even if the attacker does not know the value of R, the same value owf(R) is used to guard all of the keys and there is known correlation between corresponding bits of each X.
  • storage technique (2) is more secure, as it uses a set of different owf(R[i]) values to guard the keys.
  • storage technique (2) requires additional storage over storage technique (1).
  • the problem with storage technique (1) is that there is a single value (owf(R)) used to guard the keys, and there is known correlation between corresponding bits of each stored form of key. i.e. XOR is a poor encryption function.
  • Storage technique (2) relies on storing a different R for each key so that the values used to protect each key are uncorrelated on a single chip, and are uncorrelated between chips.
  • the problem with storage technique (2) is that additional storage is required—one R per key.
  • storage technique (3) is as follows:
  • the keys may be stored at known addresses.
  • the Encrypt function is XOR, and Q is obtained by owf(R
  • XOR is not a strong encryption technique (as can be seen by the attack in Section 2.2), but it is strong when applied to an uncorrelated data, as is the case with this method.
  • the technique used to generate Q is such that uncorrelated Qs are obtained to protect the keys, each Q is uncorrelated from the stored R, and both Rs and Qs are uncorrelated between chips.
  • a nonce is a parameter that varies with time.
  • a nonce can be a generated random number, a time stamp, and so on. Because a nonce changes with time, an entity can use it to manage its interactions with other entities.
  • a session is an interaction between two entities.
  • a nonce can be used to identify components of the interaction with a particular session.
  • a new nonce must be issued for each session.
  • a replay attack is an attack on a system which relies on replaying components of previous legitimate interactions.
  • nonces are useful in challenge-response systems to protect against replay attacks.
  • a entity referred to as a challenger
  • the incorporation of a challenger's nonce ensures that the other party in the interaction is not replaying components of a previous legitimate session, and authenticates that the message is indeed part of the session they claim to be part of.
  • an attacker can predict future nonces, then they can potentially launch attacks on the security of the system. For example, an attacker may be able to determine the distance in nonce-sequence-space from the current nonce to a nonce that has particular properties or can be used in a man-in-the-middle attack.
  • neither of these sources of random numbers may be feasible.
  • the entity may not have access to a non-deterministic physical phenomenon.
  • the entity may not have the computational power required for complex calculations.
  • What is needed for small entities is a method of generating a sequence of random numbers which has the property that the next number in the sequence is computationally difficult to predict.
  • a random number called x o is injected into the entity.
  • the random number acts as the initial seed for a sequence, and should be generated from a strong source of random numbers (e.g. a non-deterministic physically generated source).
  • the strong one-way function owf( ) can be a strong one-way hash function, such as SHA-1, or a strong non-compressing one-way function.
  • n in x needs to be sufficiently large with respect to the chosen one-way function. For example, n should be at least 160 when owf is SHA-1.
  • the seed is advanced by a simple means. For example, it may be incremented as an n-bit integer, or passed through an n-bit linear feedback shift register.
  • the entity publishes a sequence of nonces R 0 , R 1 , R 2 , R 3 , . . . based on a sequence of seeds x 0 , x 1 , x 2 , x 3 , . . . .
  • the exported sequence R 0 , R 1 , R 2 , R 3 , . . . etc., is not predictable (or deterministic) from an attacker's point of view. It is computationally difficult to predict the next number in the sequence.
  • the random sequence produced from this is not a strong random sequence e.g. from the view of guaranteeing particular distribution probabilities.
  • the behaviour is more akin to random permutations. Nonetheless, it is still useful for the purpose of generating a sequence for use as a nonce in such applications as a SoC-based implementation of the QA Logical Interface.
  • functionally identical code segments are stored in each of multiple devices.
  • the device can be, for example, a series of printer cartridges, and more specifically the QA printer chip attached to such cartridges.
  • the programs stored in the devices are functionally identical to each other, which is to say that they implement the same instructions in the same way, although the individual instances of the programs may operate on different data and using different keys.
  • each code segment can be a function or other relatively self-contained subset of instructions, although this is not required.
  • the program code is injected such that the position of particular code segments varies across the devices.
  • the memory location at which each code segment starts can be selected in any convenient manner. It is not strictly necessary that every segment be placed in a truly random or unique location in the memory from device to device. Rather, it is enough that a potential attacker cannot rely on the same code being in the same place in a series of different integrated circuits.
  • the location of particular code segments be selected at least pseudo-randomly, and preferably randomly.
  • an initial instruction is located at an initial memory location that is the same across all of the devices. This means that a common boot program can be used at startup, since it always looks to the initial location to commence the program. Somewhere in the code segment following the initial location, the program jumps to one of the random or pseudo-random memory locations. From this point in the program, the instructions are effectively unknown to an attacker. Of course, it is possible that only a relatively small (but preferably important) code section is located at this random or pseudo-random location. The rest of the code can be at common locations across the devices.
  • the reference to the random or pseudo-random location in the program code can be explict (as above) or implicit.
  • the program code can refer to a pointer or register that contains the location of interest.
  • the location is stored in the pointer or register during program instantiation.
  • the location of interest can also be stored in a jump table.
  • Multiple random or pseudo random locations can be used.
  • the program can jump to multiple locations during its execution, each of the locations being different across several devices.
  • the code segments themselves can be different to each other, such that even the segments themselves (in number or size) vary from device to device.
  • a variant key is associated with a base key when it is the result of applying a one way function to the base key and a bit-pattern.
  • Bit-pattern A generic term that can refer to keys, nonces, random numbers, pseudo-random numbers, serial numbers, and any other strings of interest.

Abstract

A method of storing at least one functionally identical code segment in each of a plurality of printer cartridges, each having a memory, of a printing system is provided, in which a first memory location is determined which is different than a first memory location in at least a plurality of the other printer cartridges, and a first of the at least one code segments is stored in the memory at the determined first memory location. The different first memory locations are determined such that the code segment storage location of all the respective devices cannot be ascertained from the code segment storage location of any one of the printer cartridges.

Description

    CROSS REFERENCE TO RELATED APPLICATION
  • This application is a continuation of U.S. application Ser. No. 10/854,502 filed on May 27, 2004 all of which are herein incorporated by reference.
  • FIELD OF THE INVENTION
  • The present invention relates to the storage of bit-patterns in non-volatile memory of a printer cartridge. The invention has been developed primarily for storing one or more keys in an integrated circuit, and will be described with reference to this application. However, it will be appreciated that the invention can be applied in a number of other fields where it is desirable to store bit-patterns in non-volatile memory.
  • CO-PENDING APPLICATIONS
  • Various methods, systems and apparatus relating to the present invention are disclosed in the following co-pending applications filed by the applicant or assignee of the present invention simultaneously with the present application:
    10/854521 10/854522 10/854488 10/854487 10/854503 10/854504
    10/854509 7188928 7093989 10/854497 10/854495 10/854498
    10/854511 10/854512 10/854525 10/854526 10/854516 10/854508
    10/854507 10/854515 10/854506 10/854505 10/854493 10/854494
    10/854489 10/854490 10/854492 10/854491 10/854528 10/854523
    10/854527 10/854524 10/854520

    The disclosures of these co-pending applications are incorporated herein by cross-reference.
  • CROSS-REFERENCES
  • Various methods, systems and apparatus relating to the present invention are disclosed in the following co-pending applications filed by the applicant or assignee of the present invention. The disclosures of all of these co-pending applications are incorporated herein by cross-reference.
    09/517539 6566858 6331946 6246970 6442525 09/517384
    09/505951 6374354 09/517608 6816968 6757832 6334190
    6745331 09/517541 10/636263 10/636283 10/407212 10/407207
    10/683064 10/683041 10/727181 10/727162 10/727163 10/727245
    7121639 7165824 7152942 10/727157 7181572 7096137
    10/727257 10/727238 7188282 10/727159 10/727180 10/727179
    10/727192 10/727274 10/727164 10/727161 10/727198 10/727158
    10/754536 10/754938 10/727227 10/727160 6795215 6859289
    6977751 6398332 6394573 6622923 6747760 6921144
    10/780624 10/791792 7182267 7025279 6857571 6817539
    6830198 6992791 7038809 6980323 7148992 7139091
    6947173
  • BACKGROUND
  • In embedded applications, it is often necessary to store a secret key in non-volatile memory (such as flash memory on an integrated circuit) in products that are widely distributed. In certain applications, the same key needs to be stored in multiple integrated circuits, many of which are available to a potential attacker. For example, the integrated circuit can form part of a consumable such as an ink cartridge, which are widely distributed as replacements for empty cartridges.
  • One way in which an attacker can probe an integrated circuit (or chip) for a key or other secret information is to use a focussed ion beam FIB write attack. In this attack, encapsulant is carefully removed from the circuitry and a FIB used to change one or more bits in flash memory from an unknown state into a known state. Based on the effect the change has on the behaviour of the chip, an attacker may be able to deduce certain information about the state of the attacked bit or bits. For example, if the chip no longer works, it may be determined that the state of the bit or bits was changed by the FIB.
  • If the chip is disabled by the attack, the attacker merely obtains another chip that has an identical secret key, and attempts a similar attack on a different bit or combination of bits. By repeating the attack on different bits over a number of the chips, the attacker can either directly determine the key, or can build up a statistical model that vastly reduces the number of attempts needed to crack the security offered by the key on the chip. Of course, once the key is compromised in this way, it is compromised for all other chips having this key.
  • SUMMARY OF THE INVENTION
  • In a first aspect the present invention provides a method of storing at least one functionally identical code segment in each of a plurality of printer cartridges of a printing system, each of the printer cartridges having a memory, the method comprising, for each printer cartridge:
  • (a) determining a first memory location which is different than a first memory location in at least a plurality of the other printer cartridges; and
  • (b) storing a first of the at least one code segments in the memory at the determined first memory location;
  • wherein the different first memory locations are determined such that the code segment storage location of all the respective devices cannot be ascertained from the code segment storage location of any one of the printer cartridges.
  • Optionally, at least one of the code segments in each of the printer cartridges includes an initial instruction, the initial instruction being located at an initial instruction location, the initial instruction location being the same in all the printer cartridges. Optionally, the initial instruction in each printer cartridge is indicative of the first memory location of that printer cartridge, the initial instruction is indicative of the first memory location by including an explicit reference to the memory location, and the initial instruction is indicative of the first memory location by including an implicit reference to the memory location. Optionally, the implicit reference is a pointer to a location at which the address of the first memory location is stored, and the implicit reference is a pointer to a register that holds the address of the first memory location.
  • Optionally, step (a) includes randomly selecting the first memory location, includes selecting the first memory location based on a stochastic process or mechanism, and selecting the first memory location from an existing list or sequence of memory locations.
  • Optionally, each memory is incorporated in a quality assurance chip of each printer cartridge, and is non-volatile memory.
  • Optionally, a first bit-pattern is stored in non-volatile memory of a printer cartridge, and the method comprising:
  • (a) applying a one way function to a second bit-pattern associated with the printer cartridge, thereby to generate a first result;
  • (b) applying a second function to the first result and the first bit-pattern, thereby to generate a second result; and
  • (c) storing the second result in the memory, thereby indirectly storing the first bit-pattern.
  • Optionally, a bit-pattern is stored in each of a plurality of printer cartridges, each of the printer cartridges having a memory, the method comprising, for each printer cartridge:
  • (a) determining a first memory location; and
  • (b) storing the bit-pattern at the first memory location;
  • wherein the first memory locations are different in at least a plurality of the respective printer cartridges.
  • Optionally, multiple first bit-patterns are stored in non-volatile memory of a printer cartridge, the method comprising, for each of the first bit-patterns to be stored:
  • (a) applying a one way function to a third bit-pattern based on a second bit-pattern associated with the printer cartridge, thereby to generate a first result;
  • (b) applying a second function to the first result and the first bit-pattern, thereby to generate a second result; and
  • (c) storing the second result in the memory, thereby indirectly storing the first bit-pattern;
  • wherein the third bit-patterns used for the respective first bit-patterns are relatively unique compared to each other.
  • In further aspects the present invention provides one or more printer cartridges having a bit-pattern and/or result stored therein in accordance with the method.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1. Single SoPEC A4 Simplex system
  • FIG. 2. Dual SoPEC A4 Simplex system
  • FIG. 3. Dual SoPEC A4 Duplex system
  • FIG. 4. Dual SoPEC A3 simplex system
  • FIG. 5. Quad SoPEC A3 duplex system
  • FIG. 6. SoPEC A4 Simplex system with extra SoPEC used as DRAM storage
  • FIG. 7. SoPEC A4 Simplex system with network connection to Host PC
  • FIG. 8. Document data flow
  • FIG. 9. Pages containing different numbers of bands
  • FIG. 10. Contents of a page band
  • FIG. 11. Page data path from host to SoPEC
  • FIG. 12. Page structure
  • FIG. 13. SoPEC System Top Level partition
  • FIG. 14. Proposed SoPEC CPU memory map (not to scale)
  • FIG. 15. Possible USB Topologies for Multi-SoPEC systems
  • FIG. 16. CPU block diagram
  • FIG. 17. CPU bus transactions
  • FIG. 18. State machine for a CPU subsystem slave
  • FIG. 19. Proposed SoPEC CPU memory map (not to scale)
  • FIG. 20. MMU Sub-block partition, external signal view
  • FIG. 21. MMU Sub-block partition, internal signal view
  • FIG. 22. DRAM Write buffer
  • FIG. 23. DIU waveforms for multiple transactions
  • FIG. 24. SoPEC LEON CPU core
  • FIG. 25. Linking Printhead Concept
  • FIG. 26. Equivalent signature generation
  • FIG. 27. An allocation of words in memory vectors
  • FIG. 28. Transfer and rollback process
  • DETAILED DESCRIPTION OF PREFERRED EMBODIMENT
  • Also throughout this description, “printhead module” and “printhead” are used somewhat interchangeably. Technically, a “printhead” comprises one or more “printhead modules”, but occasionally the former is used to refer to the latter. It should be clear from the context which meaning should be allocated to any use of the word “printhead”.
  • A SoPEC ASIC (Small office home office Print Engine Controller) suitable for use in price sensitive SoHo printer products is described. The SoPEC ASIC is intended to be a relatively low cost solution for linking printhead control, replacing the multichip solutions in larger more professional systems with a single chip. The increased cost competitiveness is achieved by integrating several systems such as a modified PEC1 printing pipeline, CPU control system, peripherals and memory sub-system onto one SoC ASIC, reducing component count and simplifying board design. SoPEC contains features making it suitable for multifunction or “all-in-one” devices as well as dedicated printing systems.
  • Basic features of the preferred embodiment of SoPEC include:
      • Continuous 30 ppm operation for 1600 dpi output at A4/Letter.
      • Linearly scalable (multiple SoPECs) for increased print speed and/or page width.
      • 192 MHz internal system clock derived from low-speed crystal input
      • PEP processing pipeline, supports up to 6 color channels at 1 dot per channel per clock cycle
      • Hardware color plane decompression, tag rendering, halftoning and compositing
      • Data formatting for Linking Printhead
      • Flexible compensation for dead nozzles, printhead misalignment etc.
      • Integrated 20 Mbit (2.5 MByte) DRAM for print data and CPU program store
      • LEON SPARC v8 32-bit RISC CPU
      • Supervisor and user modes to support multi-threaded software and security
      • 1 kB each of I-cache and D-cache, both direct mapped, with optimized 256-bit fast cache update.
      • 1×USB2.0 device port and 3×USB2.0 host ports (including integrated PHYs)
      • Support high speed (480 Mbit/sec) and full speed (12 Mbit/sec) modes of USB2.0
      • Provide interface to host PC, other SoPECs, and external devices e.g. digital camera
      • Enable alternative host PC interfaces e.g. via external USB/ethernet bridge
      • Glueless high-speed serial LVDS interface to multiple Linking Printhead chips
      • 64 remappable GPIOs, selectable between combinations of integrated system control components:
      • 2×LSS interfaces for QA chip or serial EEPROM
      • LED drivers, sensor inputs, switch control outputs
      • Motor controllers for stepper and brushless DC motors
      • Microprogrammed multi-protocol media interface for scanner, external RAM/Flash, etc.
      • 112-bit unique ID plus 112-bit random number on each device, combined for security protocol support
      • IBM Cu-11 0.13 micron CMOS process, 1.5V core supply, 3.3V IO.
      • 208 pin Plastic Quad Flat Pack
  • The SoPEC device can be used in several printer configurations and architectures.
  • In the general sense, every preferred embodiment SoPEC-based printer architecture will contain:
      • One or more SoPEC devices.
      • One or more linking printheads.
      • Two or more LSS busses.
      • Two or more QA chips.
      • Connection to host, directly via USB2.0 or indirectly.
      • Connections between SoPECs (when multiple SoPECs are used).
  • The Host PC rasterizes and compresses the incoming document on a page by page basis. The page is restructured into bands with one or more bands used to construct a page. The compressed data is then transferred to the SoPEC device directly via a USB link, or via an external bridge e.g. from ethernet to USB. A complete band is stored in SoPEC embedded memory. Once the band transfer is complete the SoPEC device reads the compressed data, expands the band, normalizes contone, bi-level and tag data to 1600 dpi and transfers the resultant calculated dots to the linking printhead.
  • The SoPEC device can print a full resolution page with 6 color planes. Each of the color planes can be generated from compressed data through any channel (either JPEG compressed, bi-level SMG4 fax compressed, tag data generated, or fixative channel created) with a maximum number of 6 data channels from page RIP to linking printhead color planes.
  • The mapping of data channels to color planes is programmable. This allows for multiple color planes in the printhead to map to the same data channel to provide for redundancy in the printhead to assist dead nozzle compensation.
  • Also a data channel could be used to gate data from another data channel. For example in stencil mode, data from the bilevel data channel at 1600 dpi can be used to filter the contone data channel at 320 dpi, giving the effect of 1600 dpi edged contone images, such as 1600 dpi color text.
  • The SoPEC device typically stores a complete page of document data on chip. The amount of storage available for compressed pages is limited to 2 Mbytes, imposing a fixed maximum on compressed page size. SoPEC would not be capable of printing worst case pages unless they are split into bands and printing commences before all the bands for the page have been downloaded. The page sizes in the table are shown for comparison purposes and would be considered reasonable for a professional level printing system. The SoPEC device is aimed at the consumer level and would not be required to print pages of that complexity. If a document with more complex pages is required, the page RIP software in the host PC can determine that there is insufficient memory storage in the SoPEC for that document. In such cases the RIP software can take two courses of action:
      • It can increase the compression ratio until the compressed page size will fit in the SoPEC device, at the expense of print quality, or
      • It can divide the page into bands and allow SoPEC to begin printing a page band before all bands for that page are downloaded.
  • Once SoPEC starts printing a page it cannot stop; if SoPEC consumes compressed data faster than the bands can be downloaded a buffer underrun error could occur causing the print to fail. A buffer underrun occurs if a line synchronisation pulse is received before a line of data has been transferred to the printhead.
  • Other options which can be considered if the page does not fit completely into the compressed page store are to slow the printing or to use multiple SoPECs to print parts of the page. Alternatively, a number of methods are available to provide additional local page data storage with guaranteed bandwidth to SoPEC, for example a Storage SoPEC.
  • The SoPEC is a page rendering engine ASIC that takes compressed page images as input, and produces decompressed page images at up to 6 channels of bi-level dot data as output. The bi-level dot data is generated for the Memjet linking printhead. The dot generation process takes account of printhead construction, dead nozzles, and allows for fixative generation.
  • A single SoPEC can control up to 12 linking printheads and up to 6 color channels at >10,000 lines/sec, equating to 30 pages per minute. A single SoPEC can perform full-bleed printing of A4 and Letter pages. The 6 channels of colored ink are the expected maximum in a consumer SOHO, or office Memjet printing environment:
      • CMY, for regular color printing.
      • K, for black text, line graphics and gray-scale printing.
      • IR (infrared), for Netpage-enabled applications.
      • F (fixative), to enable printing at high speed. Because the Memjet printer is capable of printing so fast, a fixative may be required on specific media types (such as calendared paper) to enable the ink to dry before the page touches a previously printed page. Otherwise the pages may bleed on each other. In low speed printing environments, and for plain and photo paper, the fixative is not be required.
  • SoPEC is color space agnostic. Although it can accept contone data as CMYX or RGBX, where X is an optional 4th channel (such as black), it also can accept contone data in any print color space. Additionally, SoPEC provides a mechanism for arbitrary mapping of input channels to output channels, including combining dots for ink optimization, generation of channels based on any number of other channels etc. However, inputs are typically CMYK for contone input, K for the bi-level input, and the optional Netpage tag dots are typically rendered to an infra-red layer. A fixative channel is typically only generated for fast printing applications.
  • SoPEC is resolution agnostic. It merely provides a mapping between input resolutions and output resolutions by means of scale factors. The expected output resolution is 1600 dpi, but SoPEC actually has no knowledge of the physical resolution of the linking printhead.
  • SoPEC is page-length agnostic. Successive pages are typically split into bands and downloaded into the page store as each band of information is consumed and becomes free.
  • SoPEC provides mechanisms for synchronization with other SoPECs. This allows simple multi-SoPEC solutions for simultaneous A3/A4/Letter duplex printing. However, SoPEC is also capable of printing only a portion of a page image. Combining synchronization functionality with partial page rendering allows multiple SoPECs to be readily combined for alternative printing requirements including simultaneous duplex printing and wide format printing.
  • The required printing rate for a single SoPEC is 30 sheets per minute with an inter-sheet spacing of 4 cm. To achieve a 30 sheets per minute print rate, this requires:
  • 300 mm×63 (dot/mm)/2 sec=105.8 □seconds per line, with no inter-sheet gap.
  • 340 mm×63 (dot/mm)/2 sec=93.3 □seconds per line, with a 4 cm inter-sheet gap.
  • A printline for an A4 page consists of 13824 nozzles across the page. At a system clock rate of 192 MHz, 13824 dots of data can be generated in 69.2 □seconds. Therefore data can be generated fast enough to meet the printing speed requirement.
  • Once generated, the data must be transferred to the printhead. Data is transferred to the printhead ICs using a 288 MHz clock (3/2 times the system clock rate). SoPEC has 6 printhead interface ports running at this clock rate. Data is 8b/10b encoded, so the throughput per port is 0.8×288=230.4 Mb/sec. For 6 color planes, the total number of dots per printhead IC is 1280×6=7680, which takes 33.3 □seconds to transfer. With 6 ports and 11 printhead ICs, 5 of the ports address 2 ICs sequentially, while one port addresses one IC and is idle otherwise. This means all data is transferred on 66.7 □seconds (plus a slight overhead). Therefore one SoPEC can transfer data to the printhead fast enough for 30 ppm printing.
  • From the highest point of view the SoPEC device consists of 3 distinct subsystems
      • CPU Subsystem
      • DRAM Subsystem
      • Print Engine Pipeline (PEP) Subsystem
  • See FIG. 13 for a block level diagram of SoPEC.
  • The CPU subsystem controls and configures all aspects of the other subsystems. It provides general support for interfacing and synchronising the external printer with the internal print engine. It also controls the low speed communication to the QA chips. The CPU subsystem contains various peripherals to aid the CPU, such as GPIO (includes motor control), interrupt controller, LSS Master, MMI and general timers. The CPR block provides a mechanism for the CPU to powerdown and reset individual sections of SoPEC. The UDU and UHU provide high-speed USB2.0 interfaces to the host, other SoPEC devices, and other external devices. For security, the CPU supports user and supervisor mode operation, while the CPU subsystem contains some dedicated security components.
  • The DRAM subsystem accepts requests from the CPU, UHU, UDU, MMI and blocks within the PEP subsystem. The DRAM subsystem (in particular the DIU) arbitrates the various requests and determines which request should win access to the DRAM. The DIU arbitrates based on configured parameters, to allow sufficient access to DRAM for all requesters. The DIU also hides the implementation specifics of the DRAM such as page size, number of banks, refresh rates etc.
  • The Print Engine Pipeline (PEP) subsystem accepts compressed pages from DRAM and renders them to bi-level dots for a given print line destined for a printhead interface that communicates directly with up to 12 linking printhead ICs.
  • The first stage of the page expansion pipeline is the CDU, LBD and TE. The CDU expands the JPEG-compressed contone (typically CMYK) layer, the LBD expands the compressed bi-level layer (typically K), and the TE encodes Netpage tags for later rendering (typically in IR, Y or K ink). The output from the first stage is a set of buffers: the CFU, SFU, and TFU. The CFU and SFU buffers are implemented in DRAM.
  • The second stage is the HCU, which dithers the contone layer, and composites position tags and the bi-level spot0 layer over the resulting bi-level dithered layer. A number of options exist for the way in which compositing occurs. Up to 6 channels of bi-level data are produced from this stage. Note that not all 6 channels may be present on the printhead. For example, the printhead may be CMY only, with K pushed into the CMY channels and IR ignored. Alternatively, the position tags may be printed in K or Y if IR ink is not available (or for testing purposes).
  • The third stage (DNC) compensates for dead nozzles in the printhead by color redundancy and error diffusing dead nozzle data into surrounding dots.
  • The resultant bi-level 6 channel dot-data (typically CMYK-IRF) is buffered and written out to a set of line buffers stored in DRAM via the DWU.
  • Finally, the dot-data is loaded back from DRAM, and passed to the printhead interface via a dot FIFO. The dot FIFO accepts data from the LLU up to 2 dots per system clock cycle, while the PHI removes data from the FIFO and sends it to the printhead at a maximum rate of 1.5 dots per system clock cycle.
  • Manufacturers of systems that require consumables (such as laser printers that require toner cartridges) have addressed the problem of authenticating consumables with varying levels of success. Most have resorted to specialized packaging that involves a patent. However this does not stop home refill operations or clone manufacture in countries with weak industrial property protection. The prevention of copying is important to prevent poorly manufactured substitute consumables from damaging the base system. For example, poorly filtered ink may clog print nozzles in an ink jet printer, causing the consumer to blame the system manufacturer and not admit the use of non-authorized consumables.
  • In addition, some systems have operating parameters that may be governed by a license. For example, while a specific printer hardware setup might be capable of printing continuously, the license for use may only authorise a particular print rate. The printing system would ideally be able to access and update the operating parameters in a secure, authenticated way, knowing that the user could not subvert the license agreement.
  • Furthermore, legislation in certain countries requires consumables to be reusable. This slightly complicates matters in that refilling must be possible, but not via unauthorized home refill or clone refill means.
  • To address these authentication problems, this document defines the QA Chip Logical Interface, which provides authenticated manipulation of a system's operating and consumable parameters. The interface is described in terms of data structures and the functions that manipulate them, together with examples of use. While the descriptions and examples are targeted towards the printer application, they are equally applicable in other domains. The QA Chip Logical Interface is now described.
  • The QA Chip Logical Interface is a logical interface, and is therefore implementation independent. Although this document does not cover implementation details on particular platforms, expected implementations include:
      • Software only
      • Off-the-shelf cryptographic hardware
      • ASICs, such as SBR4320 [2] and SOPEC [5] for physical insertion into printers and ink cartridges
      • Smart cards
  • An instance of a QA Chip Logical Interface (on any platform) is a QA Device.
  • QA Devices cannot talk directly to each other. A System is a logical entity which has one or more QA Devices connected logically (or physically) to it, and calls the functions on those QA Devices.
  • From the point of view of a QA Device receiving commands, System cannot inherently be trusted i.e. a given QA Device cannot tell if the System is trustworthy or not. System can, however, be constructed within a trustworthy environment (such as a SoPEC or within another physically secure computer system), and in these cases System can trust itself.
  • Digital signatures are used throughout the authentication protocols of the QA Chip Logical Interface. A signature is produced by passing data plus a secret key through a keyed hash function. The signature proves that the data was signed by someone who knew the secret key.
  • The signature function used throughout the QA Chip Logical Interface is HMAC-SHA1.
  • When a System is constructed within a physically/logically secure environment, then System itself is trusted, and any software/hardware running within that secure environment is trusted. A Trusted QA Device is simply a QA Device that resides within the same secure environment that System also resides in, and can therefore be trusted by System. This means that it is not possible for an attacker to subvert the communication between the System and the Trusted QA Device, or to replace the functionality of a QA Device by some other functionality. A Trusted QA Device enables a System to extend trust to external QA Devices. An example of a Trusted QA Device is a body of software inside a digitally signed program.
  • An External untrusted QA Device is a QA Device that resides external to the trusted environment of the system and is therefore untrusted. The purpose of the QA Chip Logical Interface is to allow the external untrusted QA Devices to become effectively trusted. This is accomplished when a Trusted QA Device shares a secret key with the external untrusted QA Device, or with a Translation QA Device (see below).
  • In a printing application, external untrusted QA Devices would typically be instances of SBR4320 implementations located in a consumable or the printer.
  • A Translation QA Device is used to translate signatures between QA Devices and extend effective trust when secret keys are not directly shared between QA Devices.
  • As an example, if a message is sent from QA Device A to QA Device C, but A and C don't share a secret key, then under normal circumstances C cannot trust the message because a signature generated by A cannot be verified by C. However if A and B share secret 1, and B and C share secret 2, and B is allowed to translate signatures for certain messages sent between secret 1 and secret 2, then B can be used as a Translation QA Device to allow those messages to be sent between A and C.
  • A Consumable QA Device is an external untrusted QA Device located in a consumable. It typically contains details about the consumable, including how much of the consumable remains.
  • In a printing application the consumable QA Device is typically found in an ink cartridge and is referred to as an Ink QA Device, or simply Ink QA since ink is the most common consumable for printing applications. However, other consumables in printing applications include media and impression counts, so consumable QA Device is more generic.
  • An Operating Parameter QA Device is an external untrusted device located within the infrastructure of a product, and contains at least some of the operating parameters of the application. Unlike the Trusted QA Device, an Operating Parameter QA Device is in a physically/logically untrusted section of the overall hardware/software.
  • An example of an Operating Parameter QA Device in a SoPEC-based printer system is the PrinterQA Device (or simply PrinterQA), that contains the operating parameters of the printer. The PrinterQA contains OEM and printer model information that indirectly specifies the non-upgradeable operating parameters of the printer, and also contains the upgradeable operating parameters themselves.
  • A Value Upgrader QA Device contains the necessary functions to allow a system to write an initial value (e.g. an ink amount) into another QA Device, typically a consumable QA Device. It also allows a system to refill/replenish a value in a consumable QA Device after use.
  • Whenever a value upgrader QA Device increases the amount of value in another QA Device, the value in the value upgrader QA Device is correspondingly decreased. This means the value upgrader QA Device cannot create value—it can only pass on whatever value it itself has been issued with. Thus a value upgrader QA Device can itself be replenished or topped up by another value upgrader QA Device.
  • An example of a value upgrader is an Ink Refill QA Device, which is used to fill/refill ink amount in an Ink QA Device.
  • A Parameter Upgrader QA Device contains the necessary functions to allow a system to write an initial parameter value (e.g. a print speed) into another QA Device, e.g. an Operating Parameter QA Device. It also allows a system to change that parameter value at some later date.
  • A parameter upgrader QA Device is able to perform a fixed number of upgrades, and this number is effectively a consumable value. Thus the number of available upgrades decreases by 1 with each upgrade, and can be replenished by a value upgrader QA Device.
  • Secret transport keys are inserted into QA Devices during instantiation (e.g. manufacture). These keys must be replaced by the final secret keys when the purpose of the QA Device is known. The Key Replacement QA Device implements all necessary functions for replacing keys in other QA Devices.
  • An Authenticated Read is a read of data from a non-trusted QA Device that also includes a check of the signature. When the System determines that the signature is correct for the returned data (e.g. by asking a Trusted QA Device to test the signature) then the System is able to determine that the data has not been tampered en route from the read, and was actually stored on the non-trusted QA Device.
  • An authenticated write is a write to the data storage area in a QA Device where the write request includes both the new data and a signature. The signature is based on a key that has write access permission to the region of data in the QA Device, and proves to the receiving QA Device that the writer has the authority to perform the write. For example, a Value Upgrader Refilling Device is able to authorize a system to perform an authenticated write to upgrade a Consumable QA Device (e.g. to increase the amount of ink in an Ink QA Device).
  • The QA Device that receives the write request checks that the signature matches the data (so that it hasn't been tampered with en route) and also that the signature is based on the correct authorization key.
  • An authenticated write can be followed by an authenticated read to ensure (from the system's point of view) that the write was successful.
  • A non-authenticated write is a write to the data storage area in a QA Device where the write request includes only the new data (and no signature). This kind of write is used when the system wants to update areas of the QA Device that have no access-protection.
  • The QA Device verifies that the destination of the write request has access permissions that permit anyone to write to it. If access is permitted, the QA Device simply performs the write as requested.
  • A non-authenticated write can be followed by an authenticated read to ensure (from the system's point of view) that the write was successful.
  • Authorized modification of data refers to modification of data via authenticated writes.
  • The primary purpose of a QA Device is to securely hold application-specific data. For example if the QA Device is a Consumable QA Device for a printing application it may store ink characteristics and the amount of ink remaining.
  • For secure manipulation of data:
      • Data must be clearly identified (includes typing of data).
      • Data must have clearly defined access criteria and permissions.
      • Data must be able to be transferred securely from one QA Device to another, through a potentially insecure environment.
  • In addition, each QA Device must be capable of storing multiple data elements, where each data element is capable of being manipulated in a different way to represent the intended use of that data element. For convenience, a data element is referred to as a field.
  • Each QA Device requires an identifier that allows unique identification of that QA Device by external systems, ensures that messages are received by the correct QA Device, and ensures that the same device can be used across multiple transactions.
  • Strictly speaking, the identifier only needs to be unique within the context of a key, since QA Devices only accept messages that are appropriately signed. However it is more convenient to have the instance identifier completely unique, as is the case with this design.
  • In certain circumstances it is useful for a Trusted QA Device to assume the instance identifier of an external untrusted QA Device in order to build a local trusted form of the external QA Device. It is the responsibility of the System to ensure that the correct device is used for particular messages. As an example, a Trusted QA Device in a SoPEC-based printing system has the same instance identifier as the external (untrusted) Printer QA so that the System can access functionality in the Trusted QA instead of the external untrusted Printer QA. The identifier functionality is provided by ChipId.
  • ChipId is the unique 64-bit QA Device identifier. The ChipId is set when the QA Device is instantiated, and cannot be changed during the lifetime of the QA Device.
  • A 64-bit ChipId gives a maximum of 1844674 trillion unique QA Devices.
  • Each QA Device contains a number of secret keys that are used for signature generation and verification. These keys serve three basic functions:
      • For reading, where they are used to verify that the read data came from the particular QA Device and was not altered en route.
      • For writing, where they are used to authorise modification of data.
      • For transporting keys, where they are used in the process of encrypting and transporting new keys into the QA Device.
  • All of these functions are achieved by signature generation; a key is used to generate a signature for subsequent transmission from the device, and to generate a signature to compare against a received signature. The transportation function is additionally achieved by encryption.
  • The number of secret keys in a QA Device is given by NumKeys, and has a maximum value of 256, i.e. the number of keys for a particular implementation may be less than this. For convenience, we refer to a QA Device as having NumKeys keyslots, where each keyslot contains a single key. Thus the nth keyslot contains the nth key (where n has the range 0 to NumKeys-1). The keyslot concept is useful because a keyslot contains not only the bit-pattern of the secret key, but also additional information related to the secret key and its use within the QA Device. The term Keyslot[n].xxx is used to describe the element named xxx within Keyslot n.
  • Each key is referred to as K, and the subscripted form Kn refers to the key in the nth keyslot. Thus Kn=Keyslot[n].K.
  • The length of each key is 160 bits. 160 bits was chosen because the output signature length from the signature generation function (HMAC-SHA1) is 160 bits, and a key longer than 160-bits does not add to the security of the function.
  • The security of the digital signatures relies upon keys being kept secret. To safeguard the security of each key, keys should be generated in a way that is not deterministic. Ideally the bit pattern representing a particular key should be a physically generated random number, gathered from a physically random phenomenon. Each key is initially programmed during QA Device instantiation.
  • For the convenience of the System, each key has a corresponding 18-bit KeyId which can be read to determine the identity or label of the key without revealing the value of the key itself. Since the relationship between keys and KeyIds is 1:1 (they are both stored in the same keyslot), a system can read all the KeyIds from a QA Device and know what key is stored in each of the keyslots. A KeyId of INVALID_KEYID (=0) is the only predefined id, and indicates that the key is invalid and should not be used, although the QA Device itself will not specifically prevent its use. From a system perspective, the bit pattern of a key is undefined when KeyId=INVALID_KEYID, and so cannot be guaranteed to match another key whose KeyId is also INVALID_KEYID. The bit pattern for such a key should be set to a random bit pattern for the physical security of any other keys present in the QA Device.
  • To create a digital signature, the data to be signed (d) is passed together with a secret key (k) through a key dependent one-way hash function (SIG). i.e. signature=SIGk(d). The key dependent one-way hash function used throughout the QA Chip Logical Interface is HMAC-SHA1, although from a theoretical sense any key dependent one-way hash function could be used.
  • Signatures are only of use if they can be validated i.e. QA Device A produces a signature for data and QA Device B can check if the signature is valid for that particular data. This implies that A and B must share some secret information so that they can generate equivalent signatures.
  • Common key signature generation is when QA Device A and QA Device B share the exact same key i.e. key KA=key KB. Thus the signature for a message produced by A using KA can be equivalently produced by B using KB. In other words SIGKA(d)=SIGKB(d) because key KA=key KB.
  • Variant key signature generation is when QA Device B holds a base key, and QA Device A holds a variant of that key such that KA=owf(KB,UA) where owf is a one-way function based upon the base key (KB) and a unique number in A (UA). A one-way function is required to create KA from KB or it would be possible to derive KB if KA were exposed. Thus A can produce SIGKA(message), but for B to produce an equivalent signature B must produce KA by being told UA from A and using B's base key KB. KA is referred to as a variant key and KB is referred to as the base key. Therefore, B can produce equivalent signatures from many QA Devices, each of which has its own unique variant of KB. Since ChipId is unique to a given QA Device, we conveniently use that as UA.
  • Common key signature generation is used when A and B are effectively equally available1 to an attacker. Variant key signature generation is used when B is not readily available to an attacker, and A is readily available to an attacker. If an attacker is able to determine KA, they do not know KA for any other QA Device of class A, and they are not able to determine KB.
    1The term “equally available” is relative. It typically means that the ease of availability of both are the effectively the same, regardless of price (e.g. both A and B are commercially available and effectively equally easy to come by).
  • When two or more devices share UA (in our implementation, UA is ChipId), then their variant keys can be effectively treated as common keys for signatures passed between them, but as variant keys when passed to other devices.
  • The QA Device producing or testing a signature needs to know if it must use the common or variant means of signature generation. Likewise, when a key is stored in a QA Device, the status of the key (whether it is a base or variant key) must be stored in the keyslot along with the key for future reference.
  • Therefore each keyslot contains a 1-bit Variant flag to hold the status of the key in that keyslot:
      • Variant=0 means the key in the keyslot is a base/common key
      • Variant=1 means the key in the keyslot is a variant key
  • The QA Device itself doesn't directly use the Variant setting. Instead, the System reads the value of variant from the desired keyslots in the two QA Devices (one QA Device will produce the signature, the other will check the signature) and informs the signature generation function and signature checking functions whether or not to use base or variant signature generation for a particular operation.
  • It is assumed in equivalent signature generation between 4 QA Devices A, B, C that each device has a single keyslot. KeySlot.KeyId of all four keys are the same i.e KeySlot[A].KeyId=KeySlot[B].KeyId=KeySlot[C].KeyId=KeySlot[D].KeyId.
  • If KeySlot[A].Variant=0 and KeySlot[B].Variant=0, then a signature produced by A, can be equivalently produced by B because KA=KB.
  • If KeySlot[B].Variant=0 and KeySlot[C].Variant=1, then a signature produced by C, can be equivalently produced by B because KC=f (KB, ChipIdC). Note that B must be told ChipIdC for this to be possible.
  • If KeySlot[C].Variant=1 and KeySlot[D].Variant=1, then a signature produced by C, cannot be equivalently produced by D unless both QA Devices have the same UA (i.e. they must share the same Chip Identifier) While C and D will typically not share a ChipId, in certain circumstances the System can read a QA Device's Chip Identifier and install it into another QA Device. Then, using key transport mechanisms, the two QA Devices can come to share a common variant key, and can thence generate and check signatures with each other.
  • If KeySlot[D].Variant=1 and KeySlot[A].Variant=0, then a signature produced by D, can be equivalently produced by A because KD=f (KA, ChipIdD).
  • While it is theoretically possible that a system could permit each key to be used to perform all of these tasks, in most cases it is a security risk to allow this.
  • If any key can be used to transport any other key out of a QA Device, then a compromise of a single key means a compromise of all keys. The reason is that the compromised key can be used by an attacker to transport all other keys out of a QA Device. Some QA Devices (such as Key Replacement QA Devices) are specifically required to transport keys, while others (such as those devices used in consumables) should not ever transport their keys out.
  • During manufacture it is not always possible to know the final intended application for a given QA Device. For example, one may end up at OEM1 while another is destined for OEM2. To decouple manufacture from installation of QA Devices, it is useful to place temporary batch keys into the QA Devices. Each of these keys should be replaceable by a different batch key or a final application key, but during their temporary existence these keys must not be capable of authenticating signatures writes of data. Thus they act as a transport key.
  • Likewise, in the Key Replacement QA Device, there is a need to differentiate between final use for a key in a QA Device, and storage of a key in one QA Device for subsequent injection into another. For example, a key may be a transport key when stored in QA Device A, and although we want to store that same key in a Key Replacement QA Device B for future injection into A, we do not want that key to be used to transport keys from B. Thus, if a key is not in its final intended keyslot, then it should have no abilities in that QA Device other than being transported out, and the intended use of the key (for example whether or not it will be a transport key when installed in its final destination) needs to be associated with that key.
  • From a security point of view there should be a time when a key in a given keyslot can be guaranteed to be in its final intended form i.e. it cannot be replaced later. If a key could be replaced at any time, attackers could potentially launch a denial of service attack by replacing keys with garbage, or could replace a key with one of their own choice. As an example, suppose keys k1 and k2 are both used to read value from a QA Device, write value to the QA Device, and to transport new keys into the QA Device. If either k1 or k2 is compromised, then the compromised key could be used to transport keys of choice to replace both keys and create value in the QA Device.
  • Therefore each keyslot contains 3 □1-bit flags as follows:
      • KeyType: whether the key is a TransportKey (0) to be used for key transport and signing reads of key meta-information, or if it is a DataKey (1) to be used for signing data as well as key meta-information
      • TransportOut: whether or not the key can be transported out from this QA Device
      • UseLocally: whether or not the key is for use locally within this QA Device or not. For transport keys this means whether or not the transport key can be used to transport another key out from this QA Device.
  • The following examples assume 3 bits xyz are interpreted as:
      • x=KeyType
      • y=TransportOut
      • z=UseLocally
  • A freshly manufactured QA Device A will most likely have the 3 bits for each keyslot set to 000 so that all the keys are replaceable.
  • To replace one of A's keys (k1) by another batch key (k2), key replacement QA Device B is required where B typically contains k1 with 3 bits set to 001, and k2 with 3 bits set to 010. After k2 has been transferred into A, the 3 bits within A will be now set to 000. Thus k2 cannot be used or replaced within B, but can be replaced within A.
  • To replace one of A's keys (k1) by a final use data key (k2), key replacement QA Device B is required where B typically contains k1 with 3 bits set to 001, and k2 with 3 bits set to 110. After k2 has been transferred into A, the 3 bits within A will be now set to 101. Thus k2 can be used within A but not B, and cannot be transported out of A.
  • Although there are KeyNum keyslots in a QA Device, not all keyslots may be required for a given application. For example, a QA Device may supply 256 keyslots, but only 2 keys may be required for a particular application. The remaining keyslots need to be invalidated so they cannot be used as a reference for signature checking or signature generation.
  • When QA Device A has a keyslot with KeyType, TransportOut, and UseLocally set to 000, then the key in that keyslot can be replaced.
  • To invalidate the keyslot in A where k1 is currently residing so that no further keys can ever be stored in that keyslot, key replacement QA Device B is required where B typically contains:
  • k1 with 3 bits set to 001
  • a base key k2 with 3 bits set to 110 and a KeyId of 0
  • After k2 has been transferred into A as a variant key, the 3 bits within A will be now set to 100. Thus k2 cannot be used within A, cannot be transported out of A, and cannot be replaced. Moreover, being a variant key in A, k2 will be different for each instance of A and will therefore be contribute to the entropy of A. Any system reading the KeyIds that are present in A will see that the keyslot contains a key whose keyId is 0 (and is therefore invalid) and whose 2-bits specify that the key cannot be used.
  • Over the lifetime of a product, it may be desirable to retire a given key from use, either because of compromise or simply because it has been used for a specific length of time (and therefore to reduce the risk of compromise). Therefore the key in a keyslot needs to be invalidated by some means so that it cannot be used any more as a reference for signature checking or signature generation. From an audit-trail point of view, although a key has been retired from use, it is convenient to retain the key meta-information so that a System can know which keys have been retired.
  • In theory, a special command could be available in each QA Device to allow the caller to transform the KeyType, TransportOut, and UseLocally settings for a keyslot from some value to 100. The key in that slot would then be non-transportable non-usable, and therefore invalid. However it would not be possible to know the previous setting for the 3 bits once the key had become invalid.
  • It is therefore desirable to have a boolean in each keyslot that can be set to make a particular key invalid. If a key has been marked as invalid, then TransportOut and UseLocally are ignored and treated as 0, and the key cannot be replaced.
  • However, a single bit representation of this boolean over-complicates 4320-based implementations of QA Devices in that it is not possible to set a single bit in shadowed mode on a 4320 device (to change a key from valid to invalid). Instead, the page containing the key would need to be erased and the key reconstructed, tasks which need to take place during initial key replacement during manufacture, but which should not need to take place after the keys are all finalised.
  • Therefore each keyslot contains a 4-bit boolean (which should be nybble-aligned within the keyslot data structure) referred to as Invalid, where 0000 represents a valid key in the keyslot, and non-zero represents an invalid key. A specific command (Invalidate Key) exists in the QA Logical Interface to allow a caller to invalidate a previously valid key.
  • If Invalid is set to a non-zero value, then the key is not used regardless of the settings for KeyType, TransportOut, and UseLocally.
  • In general each QA Device contains a number of data elements (each element referred to as a field), each of which can be operated upon by one or more keys. In the general case of an arbitrary device containing keys and fields, it is useful to have a set of permissions for each key on each field. For example, key 1 may have read-only permissions on field 1, but read/write permissions on field 2 and read/decrement-only permissions on field 3.
  • Although it can cater for all possibilities, a general scheme has size and complexity difficulties when implemented on a device with low storage capacity. In addition, the complexity of such a scheme is increased, if the device has to operate correctly with power-failures e.g. an operation must not create a logical inconsistency if power is removed partway through the operation.
  • Since the actual number of keys that can be stored in a low storage capacity QA Device depends on the complexity of the program code and the size of the data structures, it is useful to minimise the functional complexity and minimise the size of the structures while not knowing the final number of keys.
  • In particular, the scheme must cope with multiple keys having the same permissions for a field to support the following situations:
  • each of the various users of the QA Device has access to a different key, such that different users can be individually included or excluded from access
  • only a subset of keys are in use at any one time
  • The concept that supports this requirement is the keygroup. A keygroup contains a number of keys, and each field has a set of permissions with respect to the keygroups. Thus keygroup 1 (containing some number of keys) may have read-only permissions on field 1, but read/write permissions on field 2 and read/decrement-only permissions on field 3.
  • In the limit case of 1 key per keygroup, with an arbitrary number of keygroups, the storage requirements for the permissions on each field would be the same as the general case without keygroups, but by limiting the number of keygroups, the storage requirements for the permissions on each field can be pre-known, constant, and is decoupled from the actual number of keys in the device.
  • The number of keygroups in a QA Device is 4. This allows for 2 different keygroups that can transfer value into the QA Device, and for 2 different keygroups that can transfer value out of a QA Device, where each of the 4 keygroups is independent of the others. Note that transport keys do not need to be allocated a keygroup since they cannot be used to authorise reads or writes of data.
  • Thus each keyslot contains a 2-bit KeyGroup identifier. The value of KeyGroup is relevant only when the KeyType=DataKey.
  • For security concerns it is important that a field not be created until all the keys for a keygroup have been created. Otherwise an attacker may be able to add a known new key to an existing keygroup and thereby subvert the value associated with the field.
  • However it is not possible to simply not allow the creation of fields until all of the keys have been created. It may be that two distinct phases of programming occur, with creation of keys and data based on each phase. For example a stamp franking system may contain value in the form of ink plus a dollar amount. The keys and fields relating to ink may be injected at one physical location, while the keys and fields relating to dollars may be injected at a separate location some time later.
  • It is therefore desirable to have a boolean indicator that indicates whether a particular keygroup is locked. Once a keygroup is locked, then no more keys can be added to that keygroup. The boolean indicator is accessible per keyslot rather than as a single indicator for each keygroup in order that someone reading the keyslot information can know:
  • whether they can add any more keys to a keygroup
  • whether they can create fields with write-permissions for the keygroup
  • When a key is replaced, the keygroup for that key can be locked at the same time. This will cause the QA Device to change the status of all keys with the same KeyGroup value from keygroup-unlocked to keygroup-locked, thereby preventing the addition of any more keys in the keygroup.
  • However, a single bit representation of this boolean over-complicates 4320-based implementations of QA Devices in that it is not possible to set a single bit in shadowed mode on a 4320 device (to change a locked status from unlocked to locked). Instead, the page containing the key would need to be erased and the key reconstructed, and this would need to take place per key (where the KeyGroup matched).
  • Therefore each keyslot contains a 4-bit boolean (which should be nybble-aligned within the keyslot data structure) referred to as KeyGroupLocked, where 0000 represents that the keygroup to which the key in the keyslot belongs is unlocked (i.e. more keys can be added to the keygroup), and non-zero represents that the keygroup to which the key in the keyslot belongs is locked (i.e. more keys cannot be added to the keygroup).
  • It is finally worth noting that a Key Replacement QA Device does not need to check whether or not there are fields on the target device with write permissions related to a particular keygroup. The reason is that the target QA Device only allows field creation related to a keygroup if the keygroup is locked. Therefore if there was such a field in the target device one of the following is true:
  • the target QA Device is a fake one created by an attacker. If so, and if the attacker does not know the original key, then the replaced key will be of no value. If the attacker does know the original key, then they can determine the replacement key (since the replacement key is encrypted using the original key for transport) without creating a fake QA, and can therefore generate fake value as desired.
  • the target QA Device has come under physical attack (it's a real QA Device). If an attacker can do this, it's easier to allow the key replacement first, and then create a fake field. This situation cannot ever be detected by the Key Replacement QA Device.
  • In an ideal world (for the owner of a secret key at least), a given secret key will remain secret forever. However it is prudent to minimise the loss that could occur should a key be compromised.
  • This is further complicated in a system where all of the components of a system are stored at the user site, potentially without direct connection to a central server that could appropriately update all components after a particular time period or if a compromise is known to have occurred.
  • To create rolling keys, two QA Devices A and B are required such that A and B are intended to work together via a conceptual key k. While a single key could be used for k, it is more secure to limit the lifetime of any particular key, and to have a plan in place to remove a key from use should it be compromised.
  • Rolling keys are where multiple keys are stored in at least one of A and B such that different keys can be used at different times during the life of A and B, different instances of A and B at differing manufacture times can be programmed with different keys yet still work together, and keys can be retired from use in A and/or B.
  • In the simplest example of the problem, suppose A is embedded in a printer system that works with ink cartridges containing B. If A contains a single key k for working with B, then k is required for all Bs as long as A is deployed. A compromise of k lasts for the lifetime of A.
  • A rolling key example system for this example is where A contains multiple keys k1, k2 . . . kn, each with a different KeyId, where each of these keys has the same permissions on datafields within A (typically they will all belong to the same keygroup in A). At initial manufacture, B contains a single key k1 (that is also present in A). For a given time period k1 can be used between A and B. At some later time (or if k1 is compromised), Bs are manufactured only containing k2, and new As are manufactured only containing k2, k3 . . . kn, kn+1. At a later time, Bs are manufactured only containing k3 and new As are manufactured only containing k3, k4 . . . kn, kn+1, kn+2 etc.
  • Note that if the keys shared by A and B are all common keys, then a compromise of keys from A will compromise all future value in Bs. However if A contains the variant key form and B contains a base form of each key, then compromise of keys in A does not permit an attacker to know future keys in B and the attacker can therefore not create clone Bs until a real B is released and the base key is obtained from B. This means that the more variant keys that can be injected into A the more changes in B can be coped with out any loss of security.
  • In the example above, note that if k1 is compromised, an attacker can still manufacture clone Bs that will work on older As. It is therefore desirable to somehow invalidate k1 on older As at some point to reduce the impact of clone Bs. However it is not usually the case that an immediate cut-off point can be introduced. For example, once Bs are being manufactured with k2, existing Bs containing k1 may still be in use and are still valid. Just because k2 is used with A doesn't mean that k1 should be invalidated in A immediately. Otherwise a valid user could not then use an older valid B in A after using a newer B in A. Likewise, new As typically need to be able to work with valid old Bs. Our example assumes that newer As won't work with older Bs.
  • Therefore if overlapping timing is required, then several valid keys in use at a time instead of having only a single valid key in use at a time. Once valid Bs are known to be out of circulation (e.g. due to an expiry date associated with a B) then a key can be officially retired from being included in the manufacture of new As, and can be invalidated in old As. The more keys that can be used, the finer-grained the resolution of timing for invalidating a particular key, and hence the greater the reduction in exposure.
  • For example, B may be an ink cartridge that has a use-by date of 12 months while A is a printer that must last for 5 years:
      • If A contains 5 keys, B is issued with a new key each year, and a new A is released each year, then k1 will be in B during year1, k2 will be in B during year2 etc. As produced in year 2 will need to contain k1 since old Bs from the previous year are still valid. Only in year 3 can As be manufactured without k1, and old As can have their k1 invalidated. Clone Bs can therefore be manufactured by an attacker causing loss during year 1 and 2. After year 2, those clone Bs won't work on new As, but will continue to work on old As until k1 has been invalidated on the old As.
      • If A contains 10 keys, B is issued with a new key every 6 months, and a new A is released every 6 months, then k1 will be in B during the first 6 months, k2 will be in B during the second six months etc. As produced in the second and third 6-months will need to contain k1 since old Bs from the previous year are still valid. Only in the fourth 6-month can As be manufactured without k1, and old As can have their k1 invalidated. Clone Bs can therefore be manufactured by an attacker causing loss during year 1 and the first half of year 2. After this time, those clone Bs won't work on new As, but will continue to work on old As until k1 has been invalidated on the old As. Thus the addition of keys in A and the changing of keys at a faster rate (every 6 months compared to every year) has reduced the exposure of a compromised key without increasing any risk due to exposure of keys in A.
  • Of course if A is used with B and a B-like entity called C, then A can have 1 set of rolling keys with B, and can have a different set of rolling keys with C. This requires 1 key in B, 1 key in C, and two sets of multiple keys in A.
  • The rolling key structure can be extended to work with value hierarchy. Suppose A uses value from B, and value in B is replenished by C, then A and B can have one set of rolling keys, and B and C can have a different set of rolling keys and each set of rolling keys can roll at different times and rates. In this example:
      • A contains multiple variants for use with B
      • B contains 1 base key for use with A, and multiple variants for use with C
      • C contains 1 base key for use with B
      • A compromise of key(s) in a A does not allow an attacker to manufacture clone Bs
      • A compromise of key(s) in B does not allow an attacker to manufacture clone Cs
      • A compromise of the keys in A allows free B resources on that particular A only—no other As are affected
      • A compromise of the base key in B has a limited exposure of effect—free B resources are available to attackers for a limited time, and with each new release of A and C, the amount of exposure is reduced.
      • A compromise of the base key in C has a limited exposure of effect—free C resources are available to attackers for a limited time, and with each new release of B the amount of exposure is reduced.
  • In the general case, each of the keys in a set of rolling keys has exactly the same purpose as the others in the set, and is used in the same way in the same QA Devices, but at different times in a product's life span. Each of the keys has a different KeyId. Typically when a set of rolling keys is held in a QA Device, they all belong to the same keygroup.
  • When the variant/base form of rolling keys is used, at any given time, only one base key is injected during manufacture. This is the current manufactured instance of the rolling key. Several of the key instances can be used in manufacture, in their variant forms. One by one, the current manufactured instance of the rolling key is replaced by subsequent instances of the rolling key.
  • After a period, or after the discovery of a key compromise, a particular current manufactured instance of a key is replaced by the next instance in the rolling key set in all of the QA Devices where it is used.
  • A set of rolling keys has the following characteristics:
      • The number of instances in the set of rolling keys, N. The rolling key instances are from 0 to N−1.
      • The current manufactured instance of the rolling key. This is the rolling key instance which is currently being inserted into manufactured products, in base form. The current manufactured instance is rolled to the next instance when a suitable length of time has elapsed, or there is the discovery of a key compromise.
      • The first and last valid instances of the rolling key set. There is likely to be a number of valid key instances either side of the current manufactured instance at any given time.
  • Rolling key instances which are before the first valid instance are considered to be invalid, and they should be invalidated in any manufactured product in the field whenever they are found. The question is how to enforce the eradication process, especially if the QA Devices are not in direct contact with a central authority of some kind.
  • The QA Logical Interface allows a particular key in a keyslot to be invalidated. An external entity needs to know which keys are invalid (for example by knowing the invalid keys' KeyIds). Assuming that the entity can read the KeyIds present in a QA Device the entity can invalidate the appropriate keys in the QA Device. The entity could refuse to operate on a QA Device until the appropriate keys have been invalidated.
  • For example, suppose a printer system has an ink cartridge and a refill cartridge. The printer system uses rolling key set 1 to communicate with the ink cartridge, and the ink cartridge is refilled from the refill cartridge via rolling key set 2. Whenever a refill cartridge is attached to the system, the refill cartridge contains a specific field containing an invalid key list. The system software in the printer knows that this field contains an invalid key list, and refuses to transfer the ink value from the refill cartridge to the ink cartridge until it has invalidated the appropriate keys on the ink cartridge. Alternatively, every time the system software for the printer is delivered/updated to the printer (e.g. downloaded off the internet), it can contain a list of known invalid keys and can apply these to anything it is connected to, including ink cartridges and refill cartridges. Likewise, if value is injected into a QA Device over the internet, the value server can invalidate the appropriate keys on the QA Device before injection of value. Done correctly, the invalid keys will be deleted from use in all valid systems, thereby reducing the effect of a clone product.
  • The methods just discussed do not apply if a user exclusively uses fake QA Devices, and never comes into contact with valid QA Devices that have lists of invalid keys. However it is possible that a system can invalidate a key by itself after a particular amount of time, but this requires the system to know the current time, and the time period between invalidating keys. While this provides the feature required, it should not be possible under normal circumstances for a user to lie about the time or to accidentally have the time set to an incorrect one. For example, suppose a user accidentally sets a clock on their computer to the wrong year in the future, the printer attached to the computer should not suddenly invalidate all of the keys for the next 12 months. Likewise, if the user changes the clock back to the previous year, previously invalid keys should not suddenly become valid. This implies the system needs to know a Most Recent Validated Date i.e. a date/time that is completely trustworthy.
  • If system is in a trusted environment and has an appropriate time keeping mechanism, then MostRecentValidatedDate can be obtained locally. Otherwise the MostRecentValidatedDate can only be obtained when the system comes into contact with another trusted component. The trusted component could be software that runs on system, with a particular build date (and this date is therefore trusted), or a date stored on a QA Device (providing the date is read from the QA Device via keys and can only be set by a trusted source).
  • It is therefore convenient that at least one of the QA Devices in systems that support rolling keys should define at least two fields for the purposes of key invalidation: a field that contains the invalid key list (a list of invalid keyIds), and a field that contains a date that can contribute to a MostRecentValidatedDate. The Logical QA Interface currently supports a field type specifically for the former (see Appendix B), while the latter depends on the specifics of a particular application.
  • When allocating KeyIds in a system, it may be convenient to be able to tell if two keys are in the same set of rolling keys simply from based on their KeyIds (therefore independent of instantiation in a keygroup). One way of doing this is to compose the KeyId as 2 parts:
      • the RollingKeySetId, which would be unique for a given purpose within a QA Device infrastructure
      • the RollingKeyInstance, which specifies the keys within the rolling key set
  • So, for example, if the 18-bit KeyId could be composed of a 10-bit RollingKeySetId, and an 8-bit RollingKeyInstance. Thus each set of rolling keys would have 256 unique key values to be used in the sequence.
  • Suppose we have a configuration that consists of a system A that communicates with a QA Device B. For example, a printer system that communicates with an Operating Parameter QA Device (e.g. containing the print speed). The system reads the print speed before printing a page.
  • The only way that A and B can securely communicate is if A and B share a key.
  • If B has physical security since it is a QA Device, and A does not have such high security, then it is desirable to store the variant form of the key in A and the base form of the key in B. If the key is extracted from A (having less security than B), then at least other systems cannot be subverted with clone Bs.
  • However there is the question of injecting the variant key into A. If A can be programmed with a variant key after B has been attached (e.g. A contains non-volatile memory), then this is desirable. If A cannot be programmed after B has been attached (such as is the case with the SoPEC ASIC) then A must be programmed with a random number and after attachment to A, the random number must be transported into B.
  • A can now create a Trusted QA Device and communicate with B using A's variant key.
  • However if A requires to communicate with additional components such as C and D which are not connected to A or B during initial manufacture, there is a requirement to allow the communication but additionally minimise loss due to key compromise, especially since A is known to be less secure than QA Devices B, C and D. Examples of C and D include a Consumable QA Device such as an ink cartridge, and a Parameter Upgrader QA Device such as a permanent speed-upgrade dongle.
  • If the base key that is used in B is also used in C and D, then A can communicate securely with C and D. The risk of loss from a key compromise is higher since C and D share the same key.
  • If A can hold many keys, i.e. can be programmed with many keys during manufacture, then A can be programmed with appropriate variant keys for C and D using the same scheme as described above for B.
  • However, if the cost of injecting multiple keys into A is high (for example SoPEC has very little non-volatile memory), then an alternative is required that only uses a single key stored in A. There are two approaches to secure communication in this case: communication via key transport, and communication via signature translation.
  • The protocol for communicating with a QA Device is now described. Although the implementation of a QA Device varies, with one implementation having different capabilities from another, the same interface applies to all.
  • QA Devices are passive: commands are issued to them by the System, which is an entity mediating the communications between the QA Devices.
  • There are up to three QA Devices that are relevant to each command:
      • The Commanded QA Device, i.e. the QA Device receiving the command. This QA Device checks any incoming signature (if present), performs the command, and generates the output parameters and any outgoing signature as required.
      • The Incoming Signature QA Device, that generated the incoming signature (if it is present). This is usually a QA Device that produces and signs the input for the command as its output, but it might be a Translation QA Device.
      • The Outgoing Signature QA Device, that checks the outgoing signature (if it is present).
      • This is usually a QA Device that accepts as input the output of the command, but it might be a Translation QA Device.
  • The QA Device Protocol lists a set of commands that can be sent to a QA Device, and for each command, there is a set of valid responses. The protocol defines the features that are common to the commands.
  • A command consists of a number of 32-bit words where the first byte of the first word contains a command byte, and subsequent words contain up to four of the following blocks of data:
      • An UnsignedInputParameterBlock. This is a set of input parameters with no accompanying signature.
      • An InputSignatureCheckingBlock. This is a block of data that tells the QA Device how to check if the SignedInputParameterBlock is correctly signed. It includes the signature, and information about how it was constructed.
      • A SignedInputParameterBlock. This is a set of input parameters. It is often a list of entities, or entity descriptors. The signature in the InputSignatureCheckingBlock is over this block and the generator's and checker's nonces. A SignedInputParameterBlock has a QA Device's ChipId as its first element. If the SignedInputParameterBlock is list of entities with the modify bit set, then the ChipId must be the identifier of the chip being addressed (this ensures that a signed block for one QA Device cannot be applied to another)
      • An OutputSignatureGenerationBlock. This is a block of data that tells the QA Device how to generate a signature on the outgoing data.
  • The response to a command consists of a number of 32-bit words, where the first byte of the first word contains a response byte, and subsequent words contain up to two of the following blocks of data:
      • An OutputParameterBlock. This is often a list of entities. It may or may not be signed.
      • If it is signed, it has a QA Device's ChipId as its first element. If the OutputParameterBlock is list of entities with the modify bit clear, then the ChipId must be the identifier of the chip responding to the command.
      • An OutputSignatureCheckingBlock. This is present if the OutputParameterBlock is signed. The signature is generated according to the OutputSignatureGenerationBlock.
  • The arrangement of data within each 32-bit word is arranged in big-endian format. The assumption is that the System and the QA Device are processing the commands and responses in big-endian format.
  • All of the blocks in both command and response are length-tagged: the first 32-bit word contains a two-byte length that indicates the block length in 32-bit words, followed by the block data itself. The length is inclusive. Thus the length for a parameter block with no data content is 1.
  • The QA Device identifier ChipId is present in all SignedInputParameterBlock and signed OutputParameterBlock entity lists. This ensures that a signature over the block of data uniquely identifies the QA Device that the list is for or came from. This prevents attacks where commands that are intended for one QA Device are redirected to another, or when responses from one QA Device are passed off as being from another.
  • If the list is an incoming modify-entity list or an outgoing read-entity list, then the list ChipId must be the ChipId of the Commanded QA Device. If it is not, then the command fails.
  • If the list is an incoming read-entity list or an outgoing modify-entity list, then the list ChipId is typically the ChipId of some other QA Device.
  • A signed outgoing list of entities being read from a QA Device has a signature over a block of data that includes that QA Device's ChipId. Thus ensures that the data cannot be mistaken for data from another QA Device.
  • Similarly, a signed incoming list of entities being written to a QA Device has a signature over a block of data that includes that QA Device's ChipId. This ensures that the data cannot be wrongly applied to any other QA Device.
  • In the operation of some commands, a Commanded QA Device accepts a signed Entity List as input, where the Entity List was generated by another QA Device A, and produces a signed Entity List as output where the output is suitable to be subsequently applied to A as an incoming Entity List. These commands include: Get Key, Transfer Delta, Transfer Assign, and Start Rollback.
  • Commands in the QA Device command set are distinguished by CommandByte.
  • Table 1 describes the CommanByte values:
    Values and Interpretation for CommandByte
    CommandByte Value Description
    GET INFO
    1 Get summary of information from the QA Device
    GET CHALLENGE
    2 Get a nonce from the QA Device.
    LOCK KEY GROUPS 3 Lock a specified set of keygroups. This prevents any keys in the
    keygroups from being subsequently replaced.
    LOCK FIELD 4 Lock all field creation in the QA Device. Locking field creation
    CREATION prevents any fields from subsequently being created.
    READ 5 Read a group of key descriptors, field descriptors and/or field
    values from a QA Device.
    AUTHENTICATED 6 Read a group of key descriptors, field descriptors and/or field
    READ values from a QA Device. The results are accompanied by a
    signature to authenticate the results.
    AUTHENTICATED 7 Specify a group of key descriptors, field descriptors and/or field
    READ WITH values in a QA Device, and read the signature over that data.
    SIGNATURE ONLY
    WRITE 8 Write a group of field values to fields in the QA Device.
    AUTHENTICATED 9 Write a group of field values to fields in the QA Device. The
    WRITE write command is authenticated by a signature over the list of
    field values.
    CREATE FIELDS 10 Create a group of fields in a QA Device.
    REPLACE KEY 11 Replace a key in a QA Device.
    INVALIDATE KEY 12 Make a key in a QA Device invalid.
    GETKEY 13 Get an encrypted key from a QA Device.
    TEST 14 Request a QA Device to test the signature over an arbitrary
    block of data.
    SIGN 15 Request a QA Device to create a signature over an arbitrary
    block of data.
    TRANSFER DELTA 16 Request a QA Device to transfer some value from it to another
    QA Device where the value is correspondingly reduced in the
    Commanded QA Device).
    TRANSFER ASSIGN 17 Request a QA Device to transfer an assignment of value to
    another QA Device . . .
    START ROLLBACK 18 Request a QA Device to begin rollback proceedings to ensure
    that a previously transferred value has not and can never be used.
    ROLLBACK 19 Request a QA Device to undo a previously requested transfer of
    value to another QA Device.
  • The ResultFlag is a byte that indicates the return status from a function. Callers can use the value of ResultFlag to determine whether a call to a function succeeded or failed, and if the call failed, the specific error condition.
  • Table 2 describes the ResultFlag values and the mnemonics used in the pseudocode
    ResultFlag value description
    Mnemonic Value Description
    Pass
    0 Function completed successfully.
    Function successfully completed requested task.
    Fail 1 General failure. An error occurred during function
    processing.
    QA NotPresent 2 QA Device is not contactable
    Invalid Command 3 The QA Device does not support the command
    Bad Signature 4 Signature mismatch. The input signature didn't match the
    generated signature.
    Invalid Key 5 Invalid keyslot number. The keyslot specified is greater than
    the number of keyslots supported in the QA Device, or the
    key in the specified keyslot is invalid.
    Invalid Key Type 6 The key in the requested keyslot is the wrong type for the
    particular operation. For example, a TransportKey was
    requested for a data-based signature, or a DataKey was
    requested for a key-based signature.
    Key Number Out 7 A key was specified for a signature which had a key slot
    Of Range number out of range
    Key Not Locked 8 A command was received, authenticated by an unlocked
    key. Unlocked keys may not be used to authenticate any
    operations, with the exception of the transport of keys, to
    authenticate and encrypt new key values.
    Signature 9 A OutputSignatureGenerationBlock was not received in a
    Generation Block command which requires an outgoing signature
    Absent
    Signature 10 A OutputSignatureGenerationBlock was received in a
    Generation Block command which does not require an outgoing signature
    Wrongly Present
    Signature Block 11 A InputSignatureCheckingBlock was not received in a
    Absent command which requires an incoming signature
    Signature Block 12 A InputSignatureCheckingBlock was received in a
    Wrongly Present command which does not require an incoming signature
    Parameter Block 13 An Input Parameter Block wasn't received in a command
    Absent which requires that block, or an Output Parameter Block
    was not generated by a command which requires one.
    Parameter Block 14 An Input Parameter Block was received in a command
    Wrongly Present which does not require that block, or an Output Parameter
    Block was generated in a command that does not require
    one.
    Too Many 15 The Input Parameter Block of the command has a list of
    Entities more entities than the QA Device supports
    Too Few Entities 16 An Entity List or an Entity Descriptor List was received in a
    command or sent in a response with no entities.
    Illegal Field 17 Field Number incorrect. The field number specified in an
    Number entity descriptor does not exist.
    Illegal Entity 18 An entity descriptor in an input or output parameter block
    Descriptor list was set wrongly: it was “modify” when it needed to be
    Modify Bit “read”, or “read” when it needed to be “modify”.
    Wrong ChipId 19 The QA Device was given a command which had a
    SignedInputParameterBlock with modify-entities, or
    generated a signed OutputParameterBlock with read-
    entities, and the ChipId in the signed block was incorrect,
    i.e. not the ChipId of the QA Device.
    Illegal Entity 20 An entity in an Input Parameter Block of a command was
    received that is not legal for that command.
    No Shared Key 21 An operation was requested in a command to a QA Device
    which requires a key to be shared between it and another
    QA Device. If there is no shared key, this error is returned.
    Invalid Write 22 Permission not adequate to perform operation. For example,
    Permission trying to perform a Write or WriteAuth with incorrect
    permissions.
    Field Is Read 23 A Write or an Authenticated Write command was applied to
    Only a read-only field that had already been written once.
    Only Decrements 24 A Write or an Authenticated Write command was applied to
    Allowed a decrement-only field, which was not a decrement.
    Key Already 25 Key already locked. A key cannot be replaced if it has
    Locked already been locked.
    Illegal Key 26 An Entity Descriptor in an Entity List wrongly specified a
    Entity key value or descriptor that is not a legal entity for that
    command.
    Illegal Field 27 An Entity Descriptor in an Entity List wrongly specified a
    Entity field value or descriptor that is not a legal entity for that
    command.
    Key Not 28 A Replace Key command was received that was attempting
    Unlocked to change a locked key.
    Field Creation 29 Field creation was attempted in this QA Device, after it has
    Not Allowed been locked or there was an attempt to lock field creation
    after it had been already locked.
    Field Storage 30 The QA Device is out of storage space for new fields.
    Overflow
    Type Mismatch
    31 Type of the data from which the amount is being transferred
    in the Upgrading QA Device, doesn't match the Type of
    data to which the amount in being transferred in the Device
    being upgraded.
    Transfer Dest 32 A transfer was attempted on a field which is not capable of
    Field Invalid supporting a transfer.
    Rollback Enable 33 The rollback enable field for the QA Device being
    Field Invalid transferred to is invalid.
    No Transfer 34 There is no transfer source field available to do the transfer
    Source Field from.
    Transfer Source 35 The transfer source field doesn't have the amount required
    Field Amount for the transfer.
    Insufficient
    Invalid Operand 36 One of the command operands was invalid.
    Field Over 37 A Write or an Authenticated Write command was applied to
    Maximum a field which would have made the field value exceed the
    Allowed limit implied by its “maximum allowed” bit field.
    Transfer Fields 38 The “who I am” and “who I accept” fields in the transfer
    Incompatible source and transfer destination fields are not compatible.
    Transfer Rolled 39 A transfer was attempted which failed. The transfer was
    Back successfully rolled back, so the source and transfer fields are
    unchanged.
    No Matching 40 A Rollback was attempted on a QA Device which had no
    Previous Transfer record of having done a corresponding transfer (loss of
    previous record may occur depending on the depth of the
    rollback cache
    Key Not For 41 An operation was requested using a data key for which local
    Local Use use is not permitted.
  • Users of QA Devices must call the GetInfo function on each QA Device before calling any other functions on that device.
  • The GetInfo function tells the caller what kind of QA Device this is, what functions are available and what properties this QA Device has. The caller can use this information to correctly call functions with appropriately formatted parameters.
  • The first value returned, QA Device type, effectively identifies what kind of QA Device this is, and therefore what functions are available to callers. Source code control identifier tells the caller which software version the QA Device has. There must be a unique mapping of the source code control identifier to a body of source code, under source code control, in any released QA Device.
  • Additional information may be returned depending on the type of QA Device. The additional data fields of the output hold this additional information.
  • Table 3 describes each of the output parameters.
    Description of output parameters for GetInfo function
    Parameter #bytes Description
    ResultFlag
    1 Indicates whether the function completed successfully or not. If
    it did not complete successfully, the reason for the failure is
    returned here.
    QA Device type 1 This defines the function set that is available on this QA
    Device.
    Source Code 4 This uniquely defines the source code for the QA Device, as
    Control Identifier controlled by a source code control system.
    Key Replacement 1 Bit mask of keygroups which are not locked. Key replacement
    Allowed is allowed to add keys to those keysgroups.
    Maximum number 1 The number of keyslots the QA Device can support
    of keys
    Number of keys used 1 The number of keyslots the QA Device is currently using
    Number of key 1 The number of keygroups that the QA Device is currently using
    groups
    Field creation
    1 Non-zero if field creation is allowed
    allowed
    Number of fields 1 The number of fields which are present in the QA Device
    Number of read- 2 The number of write-once then read-only (ROS) words that the
    only words in device QA Device supports
    Number of read- 2 The number of write-once then read-only (ROS) words that the
    only words used QA Device is currently using
    Number of 2 The number of writeable (RWS) words that the QA Device
    writeable words supports
    in device
    Number of 2 The number of writeable (RWS) words that the QA Device is
    writeable words currently using
    used
    ChipId 8 This QA Device's ChipId
    VarDataLen
    1 Length of bytes to follow.
    VarData (VarDataLen This is additional application specific data, and is of length
    bytes) VarDataLen (i.e. may be 0).
  • Table 4 shows the mapping of QA Device Type:
    QA Device Types
    QADevice Type\ Description
    1 Base QA Device
    2 Value Upgrader QA Device
    3 Parameter Upgrader QA Device
    4 Key Replacement QA Device
    5 Trusted QA Device
  • Table 5 shows the mapping between the QA Device type and the available device functions on that QA Device.
    Mapping between QA Device Type and available device functions
    Supported on
    QA Device Device
    QA Device Function Types description
    Get Info all Base QA Device
    Get Challenge
    Lock Key Groups
    Lock Field Creation
    Authenticated Read
    Authenticated Write
    Non-authenticated Write
    Create Fields
    Replace Key
    Invalidate Key
    Transfer Delta
    2 Value Upgrader
    Start Rollback QA Device
    Roll Back Amount (e.g. Ink Refill
    QA Device)
    Transfer Amount 3 Parameter Upgrader
    Start Rollback QA Device
    Rollback Field (e.g. Local Upgrader
    QA Device)
    GetKey 4 Key Replacement
    QA Device
    Sign
    5 Trusted Device
    Test
  • Table 6 shows the VarData components for Value Upgrader and Parameter Upgrader QA Devices.
    VarData for Value and Parameter Upgrader QA Devices
    Length
    VarData in
    Components bytes Description
    DepthOfRollBackCache
    1 The number of data sets that can be accommodated
    in the Xfer Entry cache of the device.
  • An Authenticated Transfer is the process where a store of value is securely transferred from one QA Device to another.
  • A Rollback is where a previous attempted transfer is annulled, when the transferring QA Device is given evidence that the transfer never succeeded, and can never succeed in the future.
  • When a transfer is taking place from one QA Device to another, the QA Device from which the value is being transferred is called the Source QA Device, and the QA Device to which the value is being transferred is called the Destination QA Device.
  • The stores of values can be either consumables, or properties.
  • In a printing application, consumables are things like picolitres of ink, millimetres of paper, page impressions etc. They are things that are consumed as the printing process is taking place.
  • In a printing application, properties are things like printer features, such as the right to print at a certain number of pages per second, or the right to interwork with a certain bit of equipment, such as a larger ink cartridge, (which may be cheaper to buy per litre of ink).
  • A property can also be a printer license, which has an implied printer feature set. That is, if a printer has a license, it has a certain feature set, and other non-selectable printer features have certain default values.
  • Properties are things which are not consumed as the printing takes place, but which can be assigned to a printer and which remain as attributes of that printer.
  • Fields in QA Devices have a transfer mode, which can be one of:
      • Quantity of Consumables: the field represents a volume of consumables. It can be the destination of a transfer, and if it has TxDE enabled, then it can be the source of a transfer of consumables,
      • Single Property: this field represents a single property of a printer, such as a printer feature or a license. This field can be assigned to, as the destination of a transfer, but cannot be the source of a transfer. Once a property has been assigned, it becomes operative, and it cannot be transferred any more.
      • Quantity of Properties: this field represents a quantity of properties, which are in transmit to their final destination. It can be the destination of a transfer, and also the source of a transfer. A quantity of properties does not confer any property to the QA Device which has them: they are in transmit to the place where they can be used as properties.
      • Other: this field cannot have value transferred from or to it.
  • In general, the flow of virtual consumables is from QACo, via the OEM factories, to the consumable containers, such as ink cartridges in the home or office. The virtual consumables are created ex nihil in QACo, transferred without being created or destroyed to the home or office, and then consumed. When virtual consumables are assigned to a consumable container to be used in SOHO, it should be done in tandem with physically filling the container, so that the two are in agreement.
  • In general, the flow of properties is from QACo, via the OEM factories or OEM internet resellers, to printers and dongles, for use in the home and office. The properties are stored as quantities of properties until they get to their final destination, where they are assigned as single properties.
  • There are three general kinds of transfers, each with their corresponding rollbacks:
      • The transfer of a quantity of consumables. This is where a volume of consumables is transferred from source to destination. The transfer source field is decreased by the transfer delta amount, and the transfer destination field is increased by the same amount. This is a transfer delta.
      • The transfer of a quantity of properties. This is where a quantity of properties is transferred from source to destination. The transfer source field is decreased by the transfer delta amount, and the transfer destination field is increased by the same amount. This is also a transfer delta.
      • The assignment of a single property. This is where a single property is transferred from source to destination. The transfer source field is decreased by 1, and the transfer destination field is assigned with the property value. This is also a transfer assignment.
  • The transfer process has two basic requirements:
      • The transfer can only be performed if the transfer request is valid. The validity of the transfer request must be completely checked by the Source QA Device before it produces the required output for the transfer. It must not be possible to apply the transfer output to the Destination QA Device if the Source QA Device has already been rolled back for that particular transfer.
      • A process of rollback is available if the transfer was not received by the Destination QA Device. A rollback is performed only if the rollback request is valid. The validity of the rollback request must be completely checked by the Source QA Device, before it adjusts its value to a previous value before the transfer request was issued. It must not be possible to rollback an Source QA Device for a transfer which has already been applied to the Destination QA Device i.e the Source QA Device must only be rolled back for transfers that have actually failed. Similarly, it must not be possible to apply a transfer to the Destination QA Device after the rollback has been applied.
  • The transfer and rollback process is shown in FIG. 28.
  • The steps shown in FIG. 28 for a transfer and rollback process are:
      • The System performs an Authenticated Read of fields and keys in the destination QA Device. The output from the read includes field data, field descriptors, and the key descriptor of the key being used to authenticate the transfer, and a signature. It is essential that the fields are read together. This ensures that the fields are correct, and have not been modified, or substituted from another device.
      • The System requests a Transfer from the Source QA Device with the amount that must be transferred, the field in the Source QA Device the amount must be transferred from, and the field in Destination QA Device the amount must be transferred to. The Transfer also includes the output from (1). The Source QA Device validates the Transfer based on the Authenticated Read output, checks that it has enough value for a successful transfer, and then produces the necessary transfer output. The transfer output typically consists of new field data for the field being refilled or upgraded, additional field data required to ensure the correctness of the transfer/rollback, along with a signature.
      • The System then applies the transfer output to the Destination QA Device, by calling an Authenticated Write function on it, passing in the transfer output from (2). The Write is either successful or not. If the Write is not successful, then the System may repeat calling the Write function using the same transfer output, which may be successful or not. If unsuccessful, the System initiates a Rollback of the transfer. The Rollback must be performed on the Source QA Device, so that it can adjust its value to a previous value before the current Transfer was initiated. It is not necessary to perform a rollback immediately after a failed Transfer. The Destination QA Device can still be used.
      • The System starts a Rollback by reading the fields and keys of the Destination QA Device.
  • The System makes a Start RollBack request to the Source QA Device with same input parameters as the Transfer, and the output from Read in (4). The Source QA Device validates the Start RollBack Request based on the Read output, and then produces the necessary Start Rollback output. The Start Rollback output consists only of additional field data along with a signature.
      • The System then applies the Start Rollback output to the Destination QA Device, by calling an Authenticated Write function on it, passing in the Start Rollback output. The Write is either successful or not. If the Write is not successful, then either (6), or (5) and (6) must be repeated.
      • The System then does an Authenticated Read of the fields of the Destination QA Device.
      • The System makes a RollBack request to the Source QA Device with same input parameters as the Transfer request, and the output from Read (7). The Source QA Device validates the RollBack request based on the Authenticated Read output, and then rolls back its field corresponding to the transfer.
  • There are two fields in every QA Device which can be the destination of a transfer, called the rollback enable fields.
  • The rollback enable fields are called RollbackEnable1 and RollbackEnable2 with field types=TYPE_ROLLBACK_ENABLE 1 and TYPE_ROLLBACK_ENABLE 2 respectively (see Table 329). They each have a transfer mode of “other”, which means that they are never the destination field of a transfer, that is, they never get value transferred to them. However, they take part in the authenticated writes which transfer value to other fields.
  • Both rollback enable fields are decrement-only fields, initialised to 0xFFFFFFFF when they are created, and they can only be decreased via authenticated writes.
  • When a transfer is requested, the authenticated read contains the field descriptors and field values for the rollback enable fields. The transfer source QA Device checks that they are present, and remembers their values.
  • The authenticated write for the transfer includes:
      • An assignment to the destination field being updated,
      • A decrement of −1 to RollbackEnable1, and
      • A decrement of −2 to RollbackEnable2.
  • If a rollback is requested, then the transfer source QA Device generates the arguments for an authenticated write to the transfer destination which include:
      • A decrement of −2 to RollbackEnable1, and
      • A decrement of −1 to RollbackEnable2.
  • This authenticated write only works if the transfer write had never been applied, (because otherwise the rollback write would be incrementing RollbackEnable2, which is not allowed; it is a decrement-only field.)
  • The pattern of “rollback enable value −1” and “rollback enable value −2” means that only one of the authenticated writes can be applied, not both. If the Transfer write has succeeded, then the Rollback write can never be applied, and if the Rollback write has succeeded, then the Transfer write can never be applied.
  • If the rollback write is successfully applied to the transfer destination, then another Authenticated Read is made to the rollback enable fields. This is presented as evidence to the transfer source QA Device, and if it can see that the rollback write has been successfully applied, it rolls back the transfer, and increments its source field.
  • The basic authorisation for a transfer comes from a key that has authenticated ReadWrite permission (stored in field information as KeyNum) to the destination fields in the Destination QA Device. This key is referred to as the transfer key.
  • After validating the input transfer request, the Source QA Device decrements the amount to be transferred from its source field, and produces the arguments for an authenticated write, and a signature using the transfer key.
  • The signature produced by the Source QA Device is subsequently applied to the Destination QA Device. The Destination QA Device accepts the transfer amount only if the signature is valid. Note that the signature is only valid if it was produced using the transfer key which has write permission to the destination field being written.
  • The Source QA Device validates the transfer request by matching the Type of the data in the destination field of Destination QA Device to the Type of data in the source field of the Source QA Device. This ensures that equivalent data Types are transferred e.g. a quantity of type Network_OEM1_infrared ink is not transferred into a field of type Network_OEM1_cyan ink.
  • Each field which may be transferred from or to has a compatibility word in its field descriptor. The compatibility word consists of two 16-bit fields, called “who I am” and “who I accept”. For the transfer to take place, each side must accept the other. That is expressed in this way: if (the source “who I am” bitwise-ANDed with the destination “who I accept” is non-zero) AND (the destination “who I am” bitwise-ANDed with the source “who I accept” is non-zero) are both non-zero, then the transfer can take place, otherwise it can't.
  • In addition, when a quantity of properties is being transferred, the source field's “upgrade to/from” word is used as follows:
      • If the assignment is a “transfer delta”, then the “upgrade to/from” words in the source and destination fields must match, and
      • The transfer is a “transfer assignment”, then the previous value of the property must have been the “upgrade from” value, and then the assignment is of the “upgrade to” value.
  • This is the complete list of checks that must be made by the transfer source QA Device, before a transfer is authorised.
      • The signature for the authenticated read matches
      • The keygroup for the incoming data is locked, and the key is valid, is of type DataKey, and has a UseLocally set to 1.
      • All of the incoming fields can be written or at least decremented by the incoming key.
      • The transfer source QA Device has the appropriate key for the transfer
      • The rollback enable fields are present
      • The rollback enable field descriptors are decrement-only, type=rollback enable, transfer mode=other
      • The rollback enable values are >=2
      • Source and destination field types match
      • Source and destination compatibility fields are compatible
      • If the transfer operation is “transfer delta”, then
        • Destination volume+delta<=maximum allowed at destination
        • Source volume>=delta
        • The source and destination fields either both have or both do not have an “upgrade option from/to” value
        • If the source field has an “upgrade option from/to” value, then it matches the destination field's value
        • The source and destination fields' transfer modes must be the same, and they must be either “quantity of consumables” or “quantity of properties”
      • If the transfer operation is “decrement and assign”, then
        • The source field's transfer modes must be “quantity of properties”, and the destination field's transfer mode must be “single property”
        • Destination value=“option from” value of the “upgrade option from/to” value
  • If any of these tests fail, then the transfer cannot proceed.
  • The Authenticated Write arguments should have these values:
      • The RollbackEnable1 field should have an authenticated write of its previous value—1
      • The RollbackEnable2 field should have an authenticated write of its previous value—2
  • If the transfer operation is Transfer Delta, then:
      • Destination volume should be set to original volume+delta.
  • If the transfer operation is “decrement and assign”, then
      • Destination value=“option to” value of the “upgrade option from/to” value
      • The implied delta value is 1.
  • The arguments of the Authenticated Write should have the “write/add” bit in the entity descriptors set to “add”, for the rollback enables, and the field value in the Transfer Delta case. It should be set to “write” for the field value in the Transfer Assign case. The use of the “add” option in the Authenticated Write eliminates a class of race conditions.
  • The Transfer Delta function is to transfer value, the value being a quantity of consumables or a quantity of properties. This distinction (compared to a Transfer Assign) is above.
  • It produces as its output the data and signature for updating given fields in a destination QA Device with an Authenticated Write. The data and signature when applied to the appropriate device through the Authenticated Write function, updates the fields of the device.
  • The system calls the Transfer Delta function on the upgrade device with a certain Delta. This Delta is validated by the Transfer Delta function for various rules, the function then produces the data and signature for the passing into the Authenticated Write function for the device being upgraded.
  • The Transfer Delta output consists of the new data for the field being upgraded, field data of the two rollback enable fields, and a signature using the transfer key.
  • The following data is saved in the transfer Source QA Device's Rollback Buffer:
      • The field number in the transfer source,
      • The field number in the transfer destination,
      • The key slot number in the transfer source,
      • The key slot number in the transfer destination,
      • The destination ChipId,
      • The destination rollback enable counters, values and descriptors,
      • The destination key descriptor.
      • The delta.
  • Non-volatile memory is memory that retains its state after power is removed. For example, flash memory is a form of non-volatile memory. The terms flash memory and non-volatile memory are used interchangeably in the detailed description.
  • In a flash memory, a bit can either be in its erased state or in its programmed state. These states are referred to as E and P. For a particular flash memory technology, E may be 0 or 1, and P is the inverse of E.
  • Depending on the flash technology, a FIB (Focused Ion Beam) can be used to change chosen bits of flash memory from E to P, or from P to E. Thus a FIB may be used to set a bit from an unknown state to a known state, where the known state depends on the flash memory technology.
  • An integrated circuit (IC or chip) may be manufactured with flash memory, and may contain an embedded processor for running application program code.
  • XOR is the bitwise exclusive-or function. The symbol
    Figure US20070211292A1-20070913-P00900
    is used for XOR in equations.
  • A Key, referred to as K, is an integer (typically large) that is used to digitally sign messages or encrypt secrets. K is N bits long, and the bits of K are referred to as K0 to KN−1, or Ki, where i may run from 0 to N−1.
  • The Binary Inverse of a Key is referred to as ˜K. The bits of ˜K are referred to as ˜Ki, where i may run from 0 to N−1.
  • A Random Number used for the purposes of hiding the value of a key when stored in non-volatile memory is referred to as R. The bits of R are referred to as Ri, where i may run from 0 to N−1.
  • If a function of a key K is stored in non-volatile memory, it is referred to as X. The bits of X are referred to as Xi, where i may run from 0 to N−1.
  • In embedded applications, it is often necessary to store a secret key in non-volatile memory such as flash on an integrated circuit (IC), in products that are widely distributed.
  • In certain applications, the same key is stored in multiple ICs, all available to an attacker. For example, the IC may be manufactured into a consumable and the consumable is sold to the mass market.
  • The problem is to ensure that the secret key remains secret, against a variety of attacks.
  • This document is concerned with FIB (Focussed Ion Beam) attacks on flash-based memory products. Typically a FIB attack involves changing a number of bits of flash memory from an unknown state (either E or P) into a known state (E or P). Based on the effect of the change, the attacker can deduce information about the state of the bits of the key.
  • After an attack, if the chip no longer works, it is disposed of. It is assumed that this is no impediment to the attacker, because the chips are widely distributed, and the attackers can use as many of them as they like.
  • Note that the FIB attack is a write-only attack—the attacker modifies flash memory and tests for changes of the chip behaviour.
  • Attacks that involve reading the contents of flash memory are much more difficult, given the current state of flash memory technology. However, if an attacker were able to read from the flash memory, then it would be straightforward to read the entire contents, then to disassemble the program and calculate what operations are being performed to obtain the key value. In short, all keys would be compromised if an attacker is capable of arbitrary reads of flash memory
  • Note that this document is addressing direct attacks on the keys stored in flash memory. Indirect attacks are also possible. For example, an attacker may modify an instruction code in flash memory so that the contents of the accumulator are sent out an output port. Indirect attacks are not addressed in this document.
  • If a key K consisting of N bits is stored directly in non-volatile memory, and an attacker knows both N and the location of where K is stored within the non-volatile memory, then the attacker can use a simple FIB attack to obtain K.
  • For each bit i in K:
      • The attacker uses the FIB to set Ki to P,
      • If the chip still works the attacker can deduce that the bit was originally P.
      • If the chip no longer works, then the attacker can deduce that the bit was originally E.
  • A series of FIB attacks allows the attacker to obtain the entire key. At most, an attacker requires N chips to obtain all N bits, but on average only N/2 chips are required.
  • If the attacker cannot set a bit to P, but can set it to E, then an equivalent attack is possible. i.e. For each bit i in K:
      • The attacker uses the FIB to set Ki to E.
      • If the chip still works the attacker can deduce that the bit was originally E.
      • If the chip no longer works, then the attacker can deduce that the bit was originally P.
  • Thus storing a key directly in non-volatile memory is not secure, because it is easy for an attacker to use a FIB to retrieve the key.
  • Instead of storing K directly in flash, it is possible to store R and X, where R is a random number essentially different on each chip, and X is calculated as X=K□R. Thus K can be reconstructed by the inverse operation i.e. K=X□R.
  • In this case, a simple FIB attack as described in Section 2.1 will not work, even if the attacker knows where X and R are stored. This is because the bits of X are essentially random, and will differ from one chip to the next. If the attacker can deduce that a bit of X in one chip is a certain state, then this will not have any relation to what the corresponding bit of X is in any other chip.
  • Even so, an attacker can still extract the key. For each bit i in the key:
      • The attacker uses the FIB to set both Xi and Ri to P,
      • If the chip still works, the attacker knows that Xi and Ri were originally either both P or both E. Both of these cases imply that the key bit Ki is 0.
      • If the chip no longer works, the attacker knows that exactly one of Xi and Ri was originally P and one was E. This implies that the key bit Ki is 1.
      • If the chip no longer works, replace it with a new chip.
  • If the attacker cannot set a bit to P, but can set it to E, then an equivalent attack is possible.
  • A series of FIB attacks allows an attacker to obtain the entire key. For each bit, there is a 50% chance that the chip cannot be reused because it is damaged by the attacks (this is the case where Xi< >Ri). This means that on average it will take it will take an attacker 50%×N chips to obtain all N bits.
  • Therefore this method of storing a key is not considered secure, because it is easy for an attacker to use a FIB to retrieve the key.
  • Instead of storing K directly in flash, it is possible to store K and its binary inverse ˜K in flash such that for each chip, K is stored randomly in either of 2 locations and ˜K is stored in the other of the 2 locations (the program that accesses the key also needs to know the placement). As a result, given a randomly selected chip, an attacker does not know whether the bit stored at a particular location belongs to K or ˜K.
  • If the program in flash memory checks that the value read from the first location is the binary inverse of the value stored in the second location, before K is used, and the program fails if it is not, then an attacker cannot use the behaviour of the chip to determine whether a single bit attack hit a bit of K or ˜K.
  • However the chip is subject to an attacker performing multiple-bit FIB attacks, assuming that the attacker knows the two locations where K and ˜K are stored, but does not know which location contains K; and that the program in the chip checks that the values stored at the two locations are inverses of each other, and fails if they are not.
  • For each bit i>0 in the key:
  • The attacker chooses a positive integer T.
  • The attacker repeats the following experiment up to T times, on a series of chips:
      • The attacker uses the FIB to set bits 0 and i of the value stored at one of the 2 locations (the attacker doesn't know if the value is K or ˜K) to P,
      • If the chip still works, then the attacker can deduce that K0 and Ki have the same value: they are either both 1 or both 0. This is because the bits that were attacked must have both been originally P, and the FIB left them that way, and so the chip still worked. It is not clear whether the attacked bits were in K or ˜K, and so the attacker can't deduce whether the key bits were 0 or 1, but the attacker has discovered that K0 and Ki are the same. If this result occurs, stop repeating the experiment.
      • If the chip no longer works, then the attacker can only deduce that either the bits in the key are different, (with a probability ⅔), or the bits in the key are the same but the attack hit the bits in the key or the inverse that were both E, (with a probability of ⅓). That is, the attacker can get no certain information from this result, but can get a probable result.
      • 3. After T attempts, if there have been any results that indicate that K0 and Ki have the same value, then the attacker knows that the bits are the same. Otherwise, the attacker knows that there is a (⅓)T probability that the bits are the same. The probability that K0 and Ki are the same can be made arbitrarily close to 0 by increasing T until the attacker has an appropriate level of comfort that the bits are different.
  • If the attacker cannot set a bit to P, but can set it to E, then an equivalent attack is possible.
  • At the end of the experiments, the relation of K0 to all of the other key bits Ki (i=1 to N−1), is either known or almost certainly known. This means that the key value is almost certainly known to within two guesses: one where K0=0, and the other where K0=1. For each guess, the other key bits Ki are implied by the known relations. The attacker can try both combinations, and at worst may need to try other combinations of keys based on the probabilities returned for each bit position during the experiment.
  • An attacker can use a series of FIB attacks to obtain the entire key. For each Ki, there is a 75% chance that the chip cannot be reused because it is damaged by the attacks: this is the case where the tested bits K0 and Ki were not both P. On average, it will take 1.5 attempts to determine that K0 and Ki are identical, and T attempts to find that K0 and Ki are different. This means that on average it will take it will take an attacker 75%×(T+1.5)/2×(N−1) chips to obtain the relations between K0 and the other N−1 bits.
  • Therefore this method of storing a key is not considered secure, because it is easy for an attacker to use a FIB to retrieve the key.
  • It is possible to store X, ˜X and R in flash memory where R is a random number, K is the key, X=K□R, and ˜X=˜K□R.
  • X, ˜X and R are stored in memory randomly with respect to each other, and the program that accesses the key also needs to know the placement. Thus, for a randomly selected chip it is not clear to an attacker whether a bit at a particular location belongs to X, ˜X or R.
  • It is assumed that the attacker knows where X, ˜X and R are stored, but does not know which one is stored in each of the 3 locations; and that the program in the chip checks that the stored value for X is indeed the binary inverse of the stored value for ˜X, and fails if it is not.
  • An attacker cannot extract the key using the method described in Section 2.3 because that method will reveal whether X0 is the same as Xi, (where X is one of X, ˜X and R), for an individual chip, but this can give no information about the relationship of K0 and Ki, because they are XORed with the random R that differs from chip to chip.
  • So a “pairs of bits” FIB attack cannot get the attacker any information about K.
  • However, K still susceptible to attack, by an attacker performing FIB attacks on pairs of bit pairs.
  • It is assumed that the chip is programmed with X, ˜X and R, and they are in known locations, but it is not known by the attacker what order they are in; and that the program in the chip checks that stored value for X is indeed the binary inverse of the stored value for ˜X, and fails if it is not.
  • For each bit i>0 in the key:
      • Choose a positive integer T.
      • Repeat this experiment up to T times, on a series of chips:
        • The attacker uses the FIB to set bits 0 and i of two of the entities (X, ˜X or R), to P.
        • The attacker does not know which of the entities were hit.
        • If the attacker hits bits in X and R, and all 4 of them were P, or if the attacker hits bits in ˜X and R, and all 4 of them were P, then the program will always pass. In these events, the attacker can deduce that K0 and Ki are the same. The probability of this outcome is ⅙. If this result occurs, stop repeating the experiment.
        • If the attacker hits bits in X and R, and not all 4 of them were P, or if the attacker hits bits in ˜X and R, and not all 4 of them were P, then the program will always fail. In this case the attacker can only deduce that either the bits in the key are different, or the bits in the key are the same but the attack hit the bits in the key or the inverse that were both E. That is, the attacker can get no certain information from this result, but can get a probable result. The probability of this outcome is ½. The probability of this outcome when K0=Ki is ⅙. The probability of this outcome when K0< >Ki is ⅓.
        • If the attacker hits bits in X and ˜X, then the program will always fail, because the corresponding bits in X and ˜X must be different (by definition). One bit from each bit pair must have been changed from P to E by the attack, and the program checks will fail. In this event, the attacker cannot find out any information about the bits of the key K. The probability of this outcome is ⅓. The probability of this outcome when K0=Ki is ⅙. The probability of this outcome when K0< >Ki is ⅙.
      • After T attempts, if there have been any results that indicate that K0 and Ki have the same value, then the attacker knows that the bits are the same. Otherwise, the attacker knows that there is a (⅖)T probability that the bits are the same. The probability that K0 and Ki are the same can be made arbitrarily close to 0 by increasing T. That is, the attacker can be almost certain that the bits are different.
  • If the attacker cannot set a bit to P, but can set it to E, then an equivalent attack is possible.
  • At the end of the experiments, the relation of K0 to all of the other key bits Ki (i=1 to N−1), is either known or almost certainly known. This means that the key value is almost certainly known to within two guesses: one where K0=0, and the other where K0=1. For each guess, the other key bits Ki will be implied by the known relations. The attacker can try both combinations, and at worst may need to try other combinations of keys based on the probabilities returned for each key position during the experiment.
  • Thus an attacker can use a series of FIB attacks to obtain the entire key.
  • Therefore this method of storing a key is not considered secure because it is not difficult for an attacker to use a FIB to retrieve the key.
  • The above-described attacks rely on the attacker having knowledge of where the key K and related key information are placed within flash memory.
  • If the program insertion re-links the program every time a chip is programmed, then the key and key-related information can be placed in an arbitrary random places in memory, on a per-chip basis. For any given chip, the attacker will not know where the key could be.
  • This will slow but not stop the attacker. It is still possible to launch statistical attacks to discover the key.
  • This section shows how any attack that can succeed against keys in known locations can be modified to succeed against keys that are placed in non-overlapping random locations, different for every programmed chip. The following assumptions are made:
      • That the places where the key information may be stored do not overlap with each other. That is, if a FIB attack hits a bit of key information, the attacker knows which bit of the key was hit, and
      • That the attacker knows the possible locations of the key information, and their alignment, and
      • That if a FIB attack leaves a chip reporting that the key was wrong, then it is more likely that this was because the key was corrupted, than because some part of the program code that manipulates the key was hit.
  • When an attacker attacks a bit in flash memory with a FIB attack to set its state to P there are a number of possibilities:
      • A bit can be hit that is already in the state P, and is therefore not changed. There is no change of behaviour of the chip. In some circumstances this can provide the attacker with some information.
      • A bit that is part of some key-related information can be hit, and the bit changes from state E to P. This will cause the program to fail, reporting an incorrect key value.
      • A bit that is not part of some key-related information can be hit, and the bit changes from state E to P. This may or may not cause the chip to fail for some other reason.
  • There are an equivalent set of possiblities if the attacker uses a FIB attack to set the state of a bit to E.
  • It is important to distinguish between the two kinds of failures: (a) failures where the program either reports an incorrect key value, or it is clear that the key value is incorrect, because it is unable to encrypt, and (b) other kinds of failures. If the program becomes unable to do key-related functions (encrypt, decrypt, digitally sign or check digital signatures, etc), but is otherwise functioning well, then the attacker can deduce that the most recent attack probably hit some key-related information.
  • If a program stops working, or comes up with some other unrelated error condition, then the most recent attack hit some part of the flash memory that was not key information, but was necessary for something else.
  • In the situation where K is placed into a random location in flash memory for each chip, and that the possible locations for the key cannot overlap with each other, then an attacker can extract the key.
  • For each bit i in N−1:
      • Choose a positive integer T.
      • Repeat the following experiment T times, on a series of chips:
        • The attacker chooses the address A of a potential key.
        • The attacker uses the FIB to set the Ai to P.
        • If the chip gets an error that implies that it has an incorrect key value, then probably K was actually at address A. In this case, the attacker records a hit, and records that Ki. is probably E.
        • Otherwise the attacker records a miss.
        • The attacker would do well to discard the chip, whether or not the chip failed. This is because there might be some silent damage to the chip, that could interact in unexpected ways with subsequent FIB attacks. It is safer to start each new experiment with a new chip.
  • After T attempts, the attacker has a record of how many hits Hi were recorded for bit i in the key.
  • Since there are N key bits in flash memory, out of a total of M total bits of flash memory, the attacker can expect that a key bit was hit N out of M times. Sometimes this hit would have changed a bit from E to P, and other times it would leave the bit unchanged at P.
  • The attacker is now able to observe that for each bit i, the Hi/T converge to two values: N/M and 0. If Hi/T=N/M, then Ki. is probably E, and if Hi/T=0, then Ki. is probably P.
  • To launch this attack, an attacker requires T×N chips. Note that for the experiments to be useful, T needs to be large enough to launch an attack on M.
  • If the attacker cannot set a bit to P, but can set it to E, then an equivalent attack is possible.
  • This method of storing a key is not considered secure, because it is difficult, though not impossible, for an attacker to use an FIB to retrieve the key.
  • In the situation where for each chip, K and ˜K are each placed into a random location in flash memory such that the possible locations for storage do not overlap with each other, and that the program in the chip checks that the stored values at the two locations are inverses of one another and fails if it is not, then an attacker can extract the key.
  • For each bit i in N−1:
  • Choose a positive integer T.
  • Repeat this experiment T times, on a series of chips:
      • The attacker chooses an address A (hoping it will be the address of K or ˜K).
      • The attacker uses the FIB to set bits A0 and Ai to P.
      • If the chip gets an error that implies that it has an incorrect key value, then probably either K or ˜K was actually at address A. In this case, the attacker records a hit. The attacker can also deduce that bits A0 and Ai were not both P. This can mean one of 2 things:
        • A0 and Ai were different, and they were part of K or ˜K. This implies that K0< >Ki. This happens ⅔ of the time.
        • A0 and Ai were both E, and they were part of K or ˜K. This implies that K0=Ki. This happens ⅓ of the time.
      • Otherwise the attacker records a miss.
      • The attacker would do well to discard the chip, whether or not the chip failed. This is because there might be some silent damage to the chip, that could interact in unexpected ways with subsequent FIB attacks. It is safer to start each new experiment with a new chip.
  • After T attempts, there will be a record of how many hits Hi were recorded for bit i in the key.
  • Since there are 2N bits in flash memory containing K and ˜K, out of a total of M total bits of flash memory, the attacker can expect that key-related bits were hit 2N out of M times.
  • The attacker should observe that for each bit i, the Hi/T converge to two values: N/M and N/2M. If Hi/T=N/M, then Ki is probably ˜K0, and if Hi/T=N/2M, then Ki. is probably K0.
  • At the end of the experiments, the relation of K0 to all of the other key bits Ki (i=1 to N−1), is probably known. This means that the key value is probably known to within two guesses: one where K0=0, and the other where K0=1. For each guess, the other key bits Ki will be implied by the known relations. The attacker should try both combinations.
  • To launch this attack, an attacker requires T×N chips. Note that for the experiments to be useful, T needs to be large enough to launch an attack on M.
  • If the attacker cannot set a bit to P, but can set it to E, then an equivalent attack is possible.
  • Therefore this method of storing a key is not considered secure, because although it is difficult, it is not impossible for an attacker to use a FIB to retrieve the key.
  • Storing a key in arbitrary non-overlapping places in flash memory will slow but not stop a determined attacker.
  • The same methods of attack that work for keys in known locations, work for keys in unknown locations. They are slower because they rely on statistics that are confounded with the failures that occur because of reasons other than corruption of keys.
  • A sufficient number of experiments allows the attacker to isolate the failures caused by differences in the value of the bits of keys from other failures.
  • The above-described attacks rely on the attacker having knowledge of where the key K and related key information are placed within flash memory, or knowledge that the locations where the key information may be placed do not overlap each other.
  • It is possible to place the key and key-related information in random locations in memory on a per-chip (assuming the program that references the information knows where the information is stored). For a randomly selected chip, the attacker will not know exactly where the key is stored. This will slow but not stop the attacker. It is still possible to launch statistical attacks that discover the key.
  • Any attack that can succeed against keys in known locations can be modified to succeed against keys that are placed in random locations, different for every programmed chip. The following assumptions are made:
      • If a FIB attack leaves a chip reporting that the key was wrong, then it is more likely that this was because the key was corrupted, than because some part of the program code that manipulates the key was hit.
  • Some inside information is helpful for the attack.
  • For a given computer architecture and software design, the keys will be held in memory in units of a particular word size, and those words will be held in an array of words, aligned with the word size. So, for example, a particular key might be 512 bits long, and held in an array of 32-bit words, and the words are aligned in flash memory at 32-bit boundaries. Similarly, another system might have a key that is 160 bits long, held in an array of bytes, aligned on byte boundaries.
  • Additional useful information for the attacker is the minimum alignment in flash memory for the key, denoted by W.
  • If a key is N bits long, aligned with a word-size of W, and placed in flash memory starting at an arbitrary word address, then there will be N/W bits that are aliased together from the point of view of the attacker. This is called the aliased bit group. This is because an attack on bit x in flash could be a hit to Ki, Ki+W, Ki+2W, etc, depending on which word in memory the key started.
  • For example, if a particular key is 512 bits long, and is held in an array of 32-bit words, then there are 16 elements (512/32) in each aliased bit group. Similarly, if another system's key is 160 bits long, held in an array of bytes, then there are 20 elements (160/8) in each aliased bit group.
  • When an attacker discovers something about a particular chip's key by attacking a bit of flash memory, the attacker can generally only deduce some bulk characteristics of the aliased bit group, rather than individual bits of the key. For small enough aliased bit groups, however, this can dramatically reduce the search size necessary to compromise the key.
  • The boundary conditions of aliased bit groups allows an attacker to gather particular types of statistics:
      • If a flash memory stores key related information on arbitrary bit boundaries, then the word size is 1, and the aliased bit group size is the key size. In this situation, the attacker can only gather statistics about the key bits as a whole.
      • If a flash memory stores key related information in words with an alignment greater than or equal to the key size, then the aliased bit group size is 1. In this situation, each bit of flash memory can only be a unique bit of the key, and any key-related information the attacker finds about that bit of flash memory can be applied to exactly that key bit.
  • It is in the attacker's interest for the word size to be as large as possible, so that there is a minimum of aliasing of bits.
  • When an attacker attacks a bit in flash memory with a FIB attack, there are a number of possible outcomes:
      • A bit can be hit that is already in the state P, and is therefore not changed. There is no change of behaviour of the chip. In some circumstances this can provide the attacker with some information.
      • A bit that is part of some key-related information can be hit, and the bit changes from state E to P. This will cause the chip to become unable to use its key correctly, and the program will fail.
      • A bit that is not part of some key-related information can be hit, and the bit changes from state E to P. This may or may not cause the chip to fail for some other reason.
  • There are an equivalent set of possible outcomes if the attacker uses a FIB attack to set the state of a bit to E.
  • It is important to distinguish between the two kinds of failures: (a) failures where the program becomes unable to use its key, and (b) other kinds of failures. If the program becomes unable to do key-related functions (encrypt, decrypt, digitally sign or check digital signatures, etc), but is otherwise functioning well, then the attacker can deduce that the most recent attack hit some key-related information.
  • If a program stops working, or comes up with some other unrelated error condition, then the most recent attack hit some part of the flash memory that was not key information, but was necessary for something else.
  • If the key K is placed into a random location in flash memory for each chip, then an attacker can extract the key.
  • For each bit i in 0-W-1, where W=the word size:
  • Choose a positive integer T.
  • The attacker repeat the following experiment T times, on a series of chips:
      • The attacker chooses the address A of a word in flash memory.
      • The attacker uses the FIB to set the Ai to P.
      • If the chip becomes unable to use the key K, then clearly the word at address A was in K. That is, Ai=Ki+jW, where (i+jW)<N. In this case, the attacker records a hit.
      • Otherwise the attacker records a miss.
      • The attacker would do well to discard the chip, whether or not the chip failed. This is because there might be some silent damage to the chip, that could interact in unexpected ways with subsequent FIB attacks. It is safer to start each new experiment with a new chip.
  • After T attempts, there will be a record of how many hits Hi were recorded for bit i in the word size.
  • At the end of the experiment, the attacker has W fractions Hi/T, one for every bit in the flash memory's words.
  • Since there are N key bits in flash memory, out of a total of M total bits of flash memory, the attacker can expect that a key bit was hit N out of M times. Sometimes this hit would have changed a bit from E to P, and other times it would leave the bit unchanged at P.
  • If all of the bits in the key's aliased bit group were E, then the attacker should expect that Hi/T=N/M. That is, all of the bits of a particular word bit i that hit a key bit changed it from E to P.
  • If all of the bits in the key's aliased bit group were P, then the attacker should expect that Hi/T=0. That is, all of the bits of a particular word bit i that hit a key bit left it unchanged at P.
  • If there are k bits in the aliased bit group, then the attacker should be able to observe that Bi=k(Hi/T)/(N/M) takes on k+1 values, from 0 to k, for each bit i in the flash memory words.
  • Bi is the number of bits in the aliased bit group that are E in the key. k−Bi is the number of bits in the aliased bit group that are P in the key. So the attacker knows to within a permutation what the key bit values are.
  • To launch this attack, an attacker requires T×W chips. Note that for the experiments to be useful, T needs to be large enough to launch an attack on M.
  • If the attacker cannot set a bit to P, but can set it to E, then an equivalent attack is possible.
  • Therefore this method of storing a key is not considered secure, because it is difficult, though not impossible, for an attacker to use a FIB to retrieve the key.
  • If K and ˜K are each placed into one of two random locations in flash memory for each chip, and the program checks that the stored values in both locations are binary inverses of each other and fails if they are not, then an attacker can extract the key.
  • For each bit i in 1-W−1, where W=the word size:
  • Choose a positive integer T.
  • The attacker repeat the following experiment T times, on a series of chips:
      • The attacker chooses the address A of a word in flash memory.
      • The attacker uses the FIB to set bits A0 and Ai to P.
      • If the chip becomes unable to use the key K, then clearly the word at address A was either in K or ˜K. That is, Ai=Ki+jW, or Ai=Ki+jW, where (i+jW)<N. In this case, the attacker records a hit. The attacker can also deduce that bits A0 and Ai were not both P.
      • This can mean one of 2 things:
      • A0 and Ai were different, and they were part of K or ˜K. This implies that Ki+jW< >KjW, for some j. This happens ⅔ of the time.
      • A0 and Ai were both E, and they were part of K or ˜K. This implies that Ki+jW=KjW, for some j. This happens ⅓ of the time.
      • Otherwise the attacker records a miss.
      • The attacker would do well to discard the chip, whether or not the chip failed. This is because there might be some silent damage to the chip, that could interact in unexpected ways with subsequent FIB attacks. It is safer to start each new experiment with a new chip.
  • After T attempts, there will be a record of how many hits Hi were recorded for bit i in the word size.
  • At the end of the experiment, the attacker has W−1 fractions Hi/T, one for each bit 1-W−1 in the flash memory's words.
  • If an attack hits bits Ki+jW and KjW, for some j, and those key bits are different, this will always cause a failure. If those key bits are the same, this will cause a failure half the time, on average.
  • So the attacker should expect that
  • Hi/T=(N/M)×Sum(j=0 to k−1, (if (Ki+jW=KjW) then ½ else 1)) where k is the number of elements in the aliased key group.
  • If we define Bi=(Hi/T)/(N/M), for i=1 to W-1, then the attacker finds Bi=(k−1) for the case where key bit Ki+jW< >KjW, for j in 0 to k−1. The attacker finds Bi=(k−1)/2 for the case where key bit Ki+jW=KjW, for j in 0 to k−1.
  • The attacker should try various combinations of Ki that make these equalities true. This dramatically decreases the search space necessary to compromise the key.
  • If the attacker cannot set a bit to P, but can set it to E, then an equivalent attack is possible.
  • Storing a key in arbitrary places in flash memory will slow but not stop a determined attacker.
  • The same methods of attack that work for keys in known locations work for keys in unknown locations. They are slower, because they rely on statistics that are confounded with the failures that occur because of reasons other than corruption of keys.
  • A sufficient number of experiments will allow the attacker to isolate the failures caused by differences in the value of the bits of keys, from other failures.
  • When keys are stored in flash, the key bits can be guarded by an increasingly elaborate set of operations to confound attackers. Examples of such operations include the XORing of key bits with random numbers, the storing of inverted keys, the random positioning of keys in flash memory, and so on.
  • Based on previous discussion, it seems likely that this increasingly elaborate series of guards can be attacked by an increasingly elaborate series of FIB attacks. Note however, that the number of chip samples required by an attacker to make a success likely may be prohibitively large, and thus a previously discussed storage method may be appropriately secure.
  • The basic problem of the storing and checking of keys is that the bits of the key-related entities (˜K, R, etc) can be directly correlated to the bits of the key.
  • Assuming a single key, a method of solving the problem is to guard the key bits using a value that has no correlation with the key bits as follows:
      • R and X are stored in the flash memory where R is a random number different for each chip, and X=K□owf(R), where owf( ) is a one-way function such as SHA1 (see [1]).
      • R and X may be stored at known addresses
  • For the program to use the key, it must calculate K=X□owf(R)
  • The one-way function should have the property that if there is any bit difference in the function input, there are on average differences in about half of the function output bits. SHA1 has this property.
  • If an attacker modifies even a single bit of R, it will affect multiple bits of the owf0 output and thus multiple bits of the calculated K.
  • This property makes it impossible to make use of multiple bit attacks, because if bit 0 and bit i of R are modified, this will affect on average N/2 bits of K, that may or may not include bits 0 and i. The attacker cannot deduce any information about bits of K.
  • Similarly, if bit 0 and bit i of X are modified, the attacker is able to tell if X0 and Xi were both P in this particular chip, but this will give the attacker no information about key bits Ki, because the attacker will not know the whole of R, and hence the attacker doesn't know any bits of owf(R).
  • If the attacker is restricted to FIB attacks, it doesn't matter if R and X are stored in fixed known locations, because these FIB attacks cannot extract any information about K.
  • A chip may need to hold multiple keys in flash memory. For this discussion it is assumed that a chip holds NumKeys keys, named K[0]-K[NumKeys−1]
  • These keys can be held in a number of ways.
  • They can be stored as NumKey instances of any of the insecure key storage algorithms discussed above. These key storage methods are insecure for the storage of multiple keys for the same reasons that they are insecure for the storage of single keys.
  • If the keys are stored as processed keys using the method introduced in Section 5 then there is an issue of how many random numbers are required for same storage. The two basic cases are:
      • Processed keys are stored along with a single random number R as X[0]−X[NumKeys−1], where X[i]=K[i]□owf(R)
        • Processed keys are stored along with a set of random numbers R[0]−R[NumKeys−1], in the form X[0]−X[NumKeys−1], where X[i]=K[i]□owf(R[i]).
  • Both storage techniques are immune to FIB attacks, as long as no keys have been compromised.
  • If storage technique (1) is used, and an attacker knows one of the keys, then that knowledge can be used with a FIB attack to obtain the value of another keys and hence all keys. The attack assumes that the attacker knows:
      • the location of R and X[0]−X[NumKeys−1], where X[i]=K[i]□owf(R).
      • the value of K[a], and wishes to discover the value of K[b].
  • For each bit i in the key K[b]:
      • The attacker uses the FIB to set Ri and X[a]i to P,
      • If the chip still works when it uses K[a],
        • The attacker knows that Ri and X[a]i in this particular chip were originally P,
      • The attacker uses the FIB to set X[b]i to P,
      • If the chip still works when it uses K[b], then the attacker can deduce that X[b]i was originally P, in which case K[b]i is 0.
      • If the chip no longer works when it uses K[b], then the attacker can deduce that X[b]i was originally E, in which case K[b]i is 1.
  • If the chip no longer works, then
      • repeat this procedure for K[b]i with a new chip.
  • If the attacker cannot set a bit to P, but can set it to E, then an equivalent attack is possible.
  • The attack relies on the fact that even if the attacker does not know the value of R, the same value owf(R) is used to guard all of the keys and there is known correlation between corresponding bits of each X.
  • Note that if the locations of R and X[0]−X[NumKeys−1], are randomised during program insertion, it will slow but not stop this kind of attack, for the reasons described in Section 4.
  • Therefore storage technique (2) is more secure, as it uses a set of different owf(R[i]) values to guard the keys. However storage technique (2) requires additional storage over storage technique (1).
  • The problem with storage technique (1) is that there is a single value (owf(R)) used to guard the keys, and there is known correlation between corresponding bits of each stored form of key. i.e. XOR is a poor encryption function.
  • Storage technique (2) relies on storing a different R for each key so that the values used to protect each key are uncorrelated on a single chip, and are uncorrelated between chips. The problem with storage technique (2) is that additional storage is required—one R per key.
  • However, it is possible to use a single base-value such that the bit-pattern used to protect each K is different. i.e.: storage technique (3) is as follows:
      • Processed keys are stored with a single random number R in the form X[0]−X[NumKeys−1], where X[i]=K[i]□owf(R|i), where owf( ) is a one-way function such as SHA1.
  • For the program to use a key, it must calculate K[i]=X[i]□owf(R|i).
  • The keys may be stored at known addresses.
  • In general, technique (3) stores X[i] where X[i]=Encrypt(K[i]) using key Q. The Encrypt function is XOR, and Q is obtained by owf(R|i) where R is an effectively random number per chip. Normally XOR is not a strong encryption technique (as can be seen by the attack in Section 2.2), but it is strong when applied to an uncorrelated data, as is the case with this method. The technique used to generate Q is such that uncorrelated Qs are obtained to protect the keys, each Q is uncorrelated from the stored R, and both Rs and Qs are uncorrelated between chips. It isn't quite a pure one-time-pad, since the same stored R is used each time the key is decrypted, but it is a one-time-pad with respect to the fact that each Q is different on a single chip, and each R (and hence the Qs) is different between chips.
  • The following terminology is now used:
  • A nonce is a parameter that varies with time. A nonce can be a generated random number, a time stamp, and so on. Because a nonce changes with time, an entity can use it to manage its interactions with other entities.
  • A session is an interaction between two entities. A nonce can be used to identify components of the interaction with a particular session. A new nonce must be issued for each session.
  • A replay attack is an attack on a system which relies on replaying components of previous legitimate interactions.
  • In the generation of non-deterministic sequences, nonces are useful in challenge-response systems to protect against replay attacks.
  • A entity, referred to as a challenger, can issue a nonce for each new session, and then require that the nonce be incorporated into the encrypted response or be included with the message in the signature generated from the other party in the interaction. The incorporation of a challenger's nonce ensures that the other party in the interaction is not replaying components of a previous legitimate session, and authenticates that the message is indeed part of the session they claim to be part of.
  • However, if an attacker can predict future nonces, then they can potentially launch attacks on the security of the system. For example, an attacker may be able to determine the distance in nonce-sequence-space from the current nonce to a nonce that has particular properties or can be used in a man-in-the-middle attack.
  • Therefore security is enhanced by an attacker not being able to predict future nonces.
  • To prevent these kinds of attacks, it is useful for the sequence of nonces to be hard to predict. However, it is often difficult to generate a sequence of unpredictable random numbers.
  • Generation of sequences is typically done in one of two ways:
      • An entity can use a source of genuinely random numbers, such as a physical process which is non-deterministic;
      • An entity can use a means of generating pseudo-random numbers which is computationally difficult to predict, such as the Blum Blum Shub pseudo-random sequence algorithm [1].
  • For certain entities, neither of these sources of random numbers may be feasible. For example, the entity may not have access to a non-deterministic physical phenomenon. Alternatively, the entity may not have the computational power required for complex calculations.
  • What is needed for small entities is a method of generating a sequence of random numbers which has the property that the next number in the sequence is computationally difficult to predict.
  • At a starting time, for example when the entity is programmed or manufactured, a random number called xo is injected into the entity. The random number acts as the initial seed for a sequence, and should be generated from a strong source of random numbers (e.g. a non-deterministic physically generated source).
  • When the entity publishes a nonce R, the value it publishes is a strong one-way function (owf) of the current value for x: i.e:
    R=owf(x)
  • The strong one-way function owf( ) can be a strong one-way hash function, such as SHA-1, or a strong non-compressing one-way function.
  • Characteristics of a good one-way function for this purpose are that it:
      • is easy to compute
      • produces a sufficiently large dynamic range as output for the application
      • is computationally infeasible to find an input which produces a pre-specified output (i.e.
      • it is preimage resistant). This means an attacker can't determine xn from Rn.
      • is computationally infeasible to find a second input which has the same output as any pre-specified input (i.e. it is 2nd-preimage resistant).
      • produces a large variance in the output for minimally different inputs is collision resistant over the output bit range i.e. is computationally infeasible to find any two distinct inputs x1 and x2 which produce the same output
  • The number of bits n in x needs to be sufficiently large with respect to the chosen one-way function. For example, n should be at least 160 when owf is SHA-1.
  • To advance to the next nonce, the seed is advanced by a simple means. For example, it may be incremented as an n-bit integer, or passed through an n-bit linear feedback shift register.
  • The entity publishes a sequence of nonces R0, R1, R2, R3, . . . based on a sequence of seeds x0, x1, x2, x3, . . . .
  • Because the nonce is generated by a one-way function, the exported sequence, R0, R1, R2, R3, . . . etc., is not predictable (or deterministic) from an attacker's point of view. It is computationally difficult to predict the next number in the sequence.
  • The advantages of this approach are:
      • The calculation of the next seed, and the generation of a nonce from the seed are not computationally difficult.
      • A true non-deterministic number is only required once, during entity instantiation. This moves the cost and complexity of the difficult generation process out of the entity.
      • There is no need for a source of random numbers from a non-deterministic physical process in the running system.
  • Note that the security of this sequence generation system relies on keeping the current value for x secret. If any of the x values is known, then all future values for x can be predicted and hence all future R values can be known.
  • Note that the random sequence produced from this is not a strong random sequence e.g. from the view of guaranteeing particular distribution probabilities. The behaviour is more akin to random permutations. Nonetheless, it is still useful for the purpose of generating a sequence for use as a nonce in such applications as a SoC-based implementation of the QA Logical Interface.
  • In one embodiment, functionally identical code segments are stored in each of multiple devices. The device can be, for example, a series of printer cartridges, and more specifically the QA printer chip attached to such cartridges.
  • The programs stored in the devices are functionally identical to each other, which is to say that they implement the same instructions in the same way, although the individual instances of the programs may operate on different data and using different keys.
  • Whilst the program instances are functionally identical, they are broken up into code segments that are each stored at different locations in the flash memory. For convenience, each code segment can be a function or other relatively self-contained subset of instructions, although this is not required.
  • After the chip has been manufactured, the program code is injected such that the position of particular code segments varies across the devices. The memory location at which each code segment starts can be selected in any convenient manner. It is not strictly necessary that every segment be placed in a truly random or unique location in the memory from device to device. Rather, it is enough that a potential attacker cannot rely on the same code being in the same place in a series of different integrated circuits.
  • It is still, however, desirable that the location of particular code segments be selected at least pseudo-randomly, and preferably randomly.
  • In the preferred embodiment, an initial instruction is located at an initial memory location that is the same across all of the devices. This means that a common boot program can be used at startup, since it always looks to the initial location to commence the program. Somewhere in the code segment following the initial location, the program jumps to one of the random or pseudo-random memory locations. From this point in the program, the instructions are effectively unknown to an attacker. Of course, it is possible that only a relatively small (but preferably important) code section is located at this random or pseudo-random location. The rest of the code can be at common locations across the devices.
  • The reference to the random or pseudo-random location in the program code can be explict (as above) or implicit. For example, the program code can refer to a pointer or register that contains the location of interest. The location is stored in the pointer or register during program instantiation. The location of interest can also be stored in a jump table.
  • Multiple random or pseudo random locations can be used. The program can jump to multiple locations during its execution, each of the locations being different across several devices. The code segments themselves can be different to each other, such that even the segments themselves (in number or size) vary from device to device.
  • Terms: A number of terms are used in the specification and claims. The following list includes some definitions that are to be used when these terms appear, unless a contrary meaning is clearly intended in context:
  • “Relatively unique”—Depending upon the context, this phrase generally means that a value or bit-pattern is rarely repeated across multiple devices. It is usually preferable that the value or bit-pattern is selected in a random or at least psuedo-random way. However, in some applications it is sufficient to ensure that the value or bit-pattern is merely not frequently repeated from device to device. Sometimes, a relatively small number of potential values or bit-patterns will be sufficient to make attacking a chip or other device sufficiently hard that it will not be worth attempting
  • “Associated with a base key”—A variant key is associated with a base key when it is the result of applying a one way function to the base key and a bit-pattern.
  • “Cryptographically strong”—Whilst this is a relative term, it has some use when comparing the ease with which functions can be broken when used in cryptography. For example, an XOR function, whilst useful in some circumstances in cryptography, is considerably easier to “crack” than, say, a hash function or sufficient length. Also, a hash function combined with a key into a MAC (i.e. “message authentication code”) such as HMAC-SHA1 used with a certain length of key will be cryptographically stronger if the key length is increased, up to a certain length of key.
  • “Bit-pattern”—A generic term that can refer to keys, nonces, random numbers, pseudo-random numbers, serial numbers, and any other strings of interest.
  • “Functionally identical”—Code segments that are functionally identical operate in the same way, using the same functions and subroutines as each other where each of the functions and subroutines are also functionally identical. However they may use different keys, constants or variables, and/or operate on different stored data or data and program segment code stored at different locations in memory. For example, two functionally identical code segments may each load a particular constant into a register for use in evaluating an expression, and although the order of steps taken to load the constant may differ between segments, the value of the constant may differ between segments, and the address of the constant in memory may differ between segments, the functional intent of the code segment is the same for both.
  • It will be appreciated by those skilled in the art that the foregoing represents only a preferred embodiment of the present invention. Those skilled in the relevant field will immediately appreciate that the invention can be embodied in many other forms.

Claims (17)

1. A method of storing at least one functionally identical code segment in each of a plurality of printer cartridges of a printing system, each of the printer cartridges having a memory, the method comprising, for each printer cartridge:
(a) determining a first memory location which is different than a first memory location in at least a plurality of the other printer cartridges; and
(b) storing a first of the at least one code segments in the memory at the determined first memory location;
wherein the different first memory locations are determined such that the code segment storage location of all the respective devices cannot be ascertained from the code segment storage location of any one of the printer cartridges.
2. A method according to claim 1, wherein at least one of the code segments in each of the printer cartridges includes an initial instruction, the initial instruction being located at an initial instruction location, the initial instruction location being the same in all the printer cartridges.
3. A method according to claim 2, wherein the initial instruction in each printer cartridge is indicative of the first memory location of that printer cartridge.
4. A method according to claim 3, wherein the initial instruction is indicative of the first memory location by including an explicit reference to the memory location.
5. A method according to claim 4, wherein the initial instruction is indicative of the first memory location by including an implicit reference to the memory location.
6. A method according to claim 5, wherein the implicit reference is a pointer to a location at which the address of the first memory location is stored.
7. A method according to claim 6, wherein the implicit reference is a pointer to a register that holds the address of the first memory location.
8. A method according to claim 1, wherein step (a) includes randomly selecting the first memory location.
9. A method according to claim 8, wherein step (a) includes selecting the first memory location based on a stochastic process or mechanism.
10. A method according to claim 1, wherein step (a) includes selecting the first memory location from an existing list or sequence of memory locations.
11. A method according to claim 1, wherein each memory is incorporated in a quality assurance integrated circuit of each printer cartridge.
12. A method according to claim 1, wherein the memory is non-volatile memory.
13. A method according to claim 1, for storing a first bit-pattern in non-volatile memory of a printer cartridge, the method comprising:
(a) applying a one way function to a second bit-pattern associated with the printer cartridge, thereby to generate a first result;
(b) applying a second function to the first result and the first bit-pattern, thereby to generate a second result; and
(c) storing the second result in the memory, thereby indirectly storing the first bit-pattern.
14. A method according to claim 1, for storing a bit-pattern in each of a plurality of printer cartridges, each of the printer cartridges having a memory, the method comprising, for each printer cartridge:
(a) determining a first memory location; and
(b) storing the bit-pattern at the first memory location;
wherein the first memory locations are different in at least a plurality of the respective printer cartridges.
15. A method according to claim 1, for storing multiple first bit-patterns in non-volatile memory of a printer cartridge, the method comprising, for each of the first bit-patterns to be stored:
(a) applying a one way function to a third bit-pattern based on a second bit-pattern associated with the printer cartridge, thereby to generate a first result;
(b) applying a second function to the first result and the first bit-pattern, thereby to generate a second result; and
(c) storing the second result in the memory, thereby indirectly storing the first bit-pattern;
wherein the third bit-patterns used for the respective first bit-patterns are relatively unique compared to each other.
16. A printer cartridge having a code segment stored in it in accordance with the method of claim 1.
17. A plurality of printer cartridges having respective code segments stored in them in accordance with the method of claim 1.
US11/749,123 2004-05-27 2007-05-15 Method Of Storing Code Segements In Plural Printer Cartridges Abandoned US20070211292A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/749,123 US20070211292A1 (en) 2004-05-27 2007-05-15 Method Of Storing Code Segements In Plural Printer Cartridges

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/854,502 US7243193B2 (en) 2004-05-27 2004-05-27 Storage of program code in arbitrary locations in memory
US11/749,123 US20070211292A1 (en) 2004-05-27 2007-05-15 Method Of Storing Code Segements In Plural Printer Cartridges

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US10/854,502 Continuation US7243193B2 (en) 2004-05-27 2004-05-27 Storage of program code in arbitrary locations in memory

Publications (1)

Publication Number Publication Date
US20070211292A1 true US20070211292A1 (en) 2007-09-13

Family

ID=36595292

Family Applications (2)

Application Number Title Priority Date Filing Date
US10/854,502 Active 2025-06-23 US7243193B2 (en) 2004-05-27 2004-05-27 Storage of program code in arbitrary locations in memory
US11/749,123 Abandoned US20070211292A1 (en) 2004-05-27 2007-05-15 Method Of Storing Code Segements In Plural Printer Cartridges

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US10/854,502 Active 2025-06-23 US7243193B2 (en) 2004-05-27 2004-05-27 Storage of program code in arbitrary locations in memory

Country Status (1)

Country Link
US (2) US7243193B2 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009145775A1 (en) * 2008-05-29 2009-12-03 Hewlett-Packard Development Company, L.P. Replaceable printer component including a memory storing a tag encryption mask
WO2012174169A2 (en) * 2011-06-13 2012-12-20 STMicroelectronics Asia Pacific Pte. Ltd. (Singapore) Delaying or deterring counterfeiting and/or cloning of a component
US8864277B2 (en) 2011-09-30 2014-10-21 Hewlett-Packard Development Company, L.P. Authentication systems and methods

Families Citing this family (106)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7290253B1 (en) 2003-09-30 2007-10-30 Vmware, Inc. Prediction mechanism for subroutine returns in binary translation sub-systems of computers
US20070033222A1 (en) * 2003-12-02 2007-02-08 Supersonica S. R. L. Process and system for storing managing displaying and protecting multimedia contents on external storage units
US7549718B2 (en) * 2004-05-27 2009-06-23 Silverbrook Research Pty Ltd Printhead module having operation controllable on basis of thermal sensors
US7484831B2 (en) * 2004-05-27 2009-02-03 Silverbrook Research Pty Ltd Printhead module having horizontally grouped firing order
US7188928B2 (en) 2004-05-27 2007-03-13 Silverbrook Research Pty Ltd Printer comprising two uneven printhead modules and at least two printer controllers, one of which sends print data to both of the printhead modules
US7290852B2 (en) * 2004-05-27 2007-11-06 Silverbrook Research Pty Ltd Printhead module having a dropped row
US20070083491A1 (en) * 2004-05-27 2007-04-12 Silverbrook Research Pty Ltd Storage of key in non-volatile memory
US7631190B2 (en) * 2004-05-27 2009-12-08 Silverbrook Research Pty Ltd Use of variant and base keys with two entities
US7314261B2 (en) * 2004-05-27 2008-01-01 Silverbrook Research Pty Ltd Printhead module for expelling ink from nozzles in groups, alternately, starting at outside nozzles of each group
US7607757B2 (en) * 2004-05-27 2009-10-27 Silverbrook Research Pty Ltd Printer controller for supplying dot data to at least one printhead module having faulty nozzle
US20060294312A1 (en) * 2004-05-27 2006-12-28 Silverbrook Research Pty Ltd Generation sequences
US7735944B2 (en) * 2004-05-27 2010-06-15 Silverbrook Research Pty Ltd Printer comprising two printhead modules and at least two printer controllers
US7243193B2 (en) * 2004-05-27 2007-07-10 Silverbrook Research Pty Ltd Storage of program code in arbitrary locations in memory
US7377609B2 (en) * 2004-05-27 2008-05-27 Silverbrook Research Pty Ltd Printer controller for at least partially compensating for erroneous rotational displacement
US7281777B2 (en) * 2004-05-27 2007-10-16 Silverbrook Research Pty Ltd Printhead module having a communication input for data and control
US7374266B2 (en) * 2004-05-27 2008-05-20 Silverbrook Research Pty Ltd Method for at least partially compensating for errors in ink dot placement due to erroneous rotational displacement
US7600843B2 (en) * 2004-05-27 2009-10-13 Silverbrook Research Pty Ltd Printer controller for controlling a printhead module based on thermal sensing
US8011747B2 (en) * 2004-05-27 2011-09-06 Silverbrook Research Pty Ltd Printer controller for controlling a printhead with horizontally grouped firing order
US7517036B2 (en) * 2004-05-27 2009-04-14 Silverbrook Research Pty Ltd Printhead module capable of printing a maximum of n channels of print data
US7427117B2 (en) * 2004-05-27 2008-09-23 Silverbrook Research Pty Ltd Method of expelling ink from nozzles in groups, alternately, starting at outside nozzles of each group
US7557941B2 (en) * 2004-05-27 2009-07-07 Silverbrook Research Pty Ltd Use of variant and base keys with three or more entities
US7328956B2 (en) * 2004-05-27 2008-02-12 Silverbrook Research Pty Ltd Printer comprising a printhead and at least two printer controllers connected to a common input of the printhead
US7448707B2 (en) * 2004-05-27 2008-11-11 Silverbrook Research Pty Ltd Method of expelling ink from nozzels in groups, starting at outside nozzels of each group
US7266661B2 (en) * 2004-05-27 2007-09-04 Silverbrook Research Pty Ltd Method of storing bit-pattern in plural devices
US7310625B2 (en) * 2004-08-12 2007-12-18 Sap Aktiengesellschaft Knowledge network generation
JP4198706B2 (en) * 2004-11-15 2008-12-17 株式会社メガチップス Storage device
JP4408087B2 (en) * 2005-02-08 2010-02-03 キヤノン株式会社 Image reproducing apparatus and control method thereof
JP2006256153A (en) * 2005-03-17 2006-09-28 Ricoh Co Ltd Image forming device having energy saving mode
US20070088605A1 (en) * 2005-10-19 2007-04-19 Yahoo! Inc. System and method for achieving linear advertisement impression delivery under uneven, volatile traffic conditions
US8108692B1 (en) * 2006-06-27 2012-01-31 Siliconsystems, Inc. Solid-state storage subsystem security solution
US20090180546A1 (en) * 2008-01-09 2009-07-16 Rodriguez Arturo A Assistance for processing pictures in concatenated video streams
US8416859B2 (en) 2006-11-13 2013-04-09 Cisco Technology, Inc. Signalling and extraction in compressed video of pictures belonging to interdependency tiers
US8875199B2 (en) 2006-11-13 2014-10-28 Cisco Technology, Inc. Indicating picture usefulness for playback optimization
KR20080072202A (en) * 2007-02-01 2008-08-06 삼성전자주식회사 Data processing method and apparatus
US20080255936A1 (en) * 2007-04-13 2008-10-16 Yahoo! Inc. System and method for balancing goal guarantees and optimization of revenue in advertisement delivery under uneven, volatile traffic conditions
US8082540B2 (en) * 2007-04-19 2011-12-20 International Business Machines Corporation Method for visually indicating preceding and succeeding source code lines that are executed in a graphical debugging environment
EP2183728B1 (en) * 2007-07-24 2015-03-25 Nxp B.V. Method, system and trusted service manager for securely transmitting an application to a mobile phone
US8804845B2 (en) 2007-07-31 2014-08-12 Cisco Technology, Inc. Non-enhancing media redundancy coding for mitigating transmission impairments
US8958486B2 (en) 2007-07-31 2015-02-17 Cisco Technology, Inc. Simultaneous processing of media and redundancy streams for mitigating impairments
US8126196B2 (en) * 2007-09-21 2012-02-28 Silverbrook Research Pty Ltd Method of imaging a coding pattern comprising reed-solomon codewords encoded by mixed multi-pulse position modulation
US7848142B2 (en) * 2007-10-31 2010-12-07 Micron Technology, Inc. Fractional bits in memory cells
US8718388B2 (en) 2007-12-11 2014-05-06 Cisco Technology, Inc. Video processing with tiered interdependencies of pictures
US8416858B2 (en) 2008-02-29 2013-04-09 Cisco Technology, Inc. Signalling picture encoding schemes and associated picture properties
US7940543B2 (en) * 2008-03-19 2011-05-10 Nanya Technology Corp. Low power synchronous memory command address scheme
US9594679B2 (en) * 2008-05-01 2017-03-14 Sandisk Il Ltd. Flash cache flushing method and system
US8886022B2 (en) 2008-06-12 2014-11-11 Cisco Technology, Inc. Picture interdependencies signals in context of MMCO to assist stream manipulation
US8705631B2 (en) 2008-06-17 2014-04-22 Cisco Technology, Inc. Time-shifted transport of multi-latticed video for resiliency from burst-error effects
US8699578B2 (en) 2008-06-17 2014-04-15 Cisco Technology, Inc. Methods and systems for processing multi-latticed video streams
US8971402B2 (en) 2008-06-17 2015-03-03 Cisco Technology, Inc. Processing of impaired and incomplete multi-latticed video streams
US9653004B2 (en) * 2008-10-16 2017-05-16 Cypress Semiconductor Corporation Systems and methods for downloading code and data into a secure non-volatile memory
CN102210147B (en) 2008-11-12 2014-07-02 思科技术公司 Processing of a video [AAR] program having plural processed representations of a [AAR] single video signal for reconstruction and output
WO2010096767A1 (en) 2009-02-20 2010-08-26 Cisco Technology, Inc. Signalling of decodable sub-sequences
US20100218232A1 (en) * 2009-02-25 2010-08-26 Cisco Technology, Inc. Signalling of auxiliary information that assists processing of video according to various formats
US8782261B1 (en) 2009-04-03 2014-07-15 Cisco Technology, Inc. System and method for authorization of segment boundary notifications
US8799572B2 (en) * 2009-04-20 2014-08-05 Microsoft Corporation Sliding-window multi-class striping
US8019839B2 (en) 2009-05-11 2011-09-13 Accenture Global Services Limited Enhanced network adapter framework
US8949883B2 (en) 2009-05-12 2015-02-03 Cisco Technology, Inc. Signalling buffer characteristics for splicing operations of video streams
US8279926B2 (en) 2009-06-18 2012-10-02 Cisco Technology, Inc. Dynamic streaming with latticed representations of video
JP5050019B2 (en) * 2009-08-26 2012-10-17 株式会社東芝 Source code analysis system
US8782434B1 (en) 2010-07-15 2014-07-15 The Research Foundation For The State University Of New York System and method for validating program execution at run-time
JP5895391B2 (en) * 2010-09-16 2016-03-30 株式会社リコー Printing apparatus and printing apparatus control method
CN103153633A (en) * 2010-09-28 2013-06-12 咨询卡有限公司 Printing images on a retransfer material having a predisposed artifact
TWI417727B (en) * 2010-11-22 2013-12-01 Phison Electronics Corp Memory storage device, memory controller thereof, and method for responding instruction sent from host thereof
JP2012174184A (en) * 2011-02-24 2012-09-10 Canon Inc Information processing device and control method of information processing device
US8756434B2 (en) 2011-04-08 2014-06-17 Apple Inc. System and method for executing an encrypted binary from a memory pool
US8843456B2 (en) * 2011-12-06 2014-09-23 International Business Machines Corporation Database table compression
WO2013095471A1 (en) * 2011-12-21 2013-06-27 Intel Corporation Method and apparatus for a partial-address select-signal generator with address shift
KR101986355B1 (en) * 2012-09-14 2019-06-05 삼성전자주식회사 A embedded Multimedia Card(eMMC), eMMC system including the eMMC, and a method for operating the eMMC
US9063721B2 (en) 2012-09-14 2015-06-23 The Research Foundation For The State University Of New York Continuous run-time validation of program execution: a practical approach
US11188652B2 (en) 2012-10-02 2021-11-30 Mordecai Barkan Access management and credential protection
US9342695B2 (en) * 2012-10-02 2016-05-17 Mordecai Barkan Secured automated or semi-automated systems
TW201322685A (en) * 2012-10-24 2013-06-01 Cal Comp Electronics & Comm Co System and method for restoring network configuration parameters
US8656063B1 (en) * 2012-11-09 2014-02-18 Ralink Technology Corp. Method of detecting addressing mode and electronic system thereof
US9251554B2 (en) 2012-12-26 2016-02-02 Analog Devices, Inc. Block-based signal processing
US11044076B2 (en) * 2013-02-25 2021-06-22 Hecusys, LLC Encrypted data processing
US9675871B1 (en) * 2013-03-15 2017-06-13 Ag Acquisition Corporation PC transceiver and method of using the same
CN107077496B (en) * 2015-03-21 2020-02-14 华为技术有限公司 Systems, methods, and apparatus for index compilation to optimize index usage
US9414079B1 (en) * 2015-03-23 2016-08-09 Kyocera Document Solutions Inc. Interleaving encoding
US10235176B2 (en) * 2015-12-17 2019-03-19 The Charles Stark Draper Laboratory, Inc. Techniques for metadata processing
GB2547912B (en) * 2016-03-02 2019-01-30 Advanced Risc Mach Ltd Register access control
CN111679787B (en) * 2016-04-27 2023-07-18 慧荣科技股份有限公司 Flash memory device, flash memory controller and flash memory storage management method
US10019314B2 (en) 2016-04-27 2018-07-10 Silicon Motion Inc. Flash memory apparatus and storage management method for flash memory
US10454670B2 (en) * 2016-06-10 2019-10-22 Cryptography Research, Inc. Memory optimization for nested hash operations
US10389693B2 (en) * 2016-08-23 2019-08-20 Hewlett Packard Enterprise Development Lp Keys for encrypted disk partitions
US10530970B2 (en) * 2016-09-02 2020-01-07 Microsoft Technology Licensing, Llc Automatic output metadata determination based on output device and substrate
CN106656200B (en) * 2016-12-13 2019-11-08 合肥工业大学 A kind of program counter compression method and its hardware circuit
US10372625B2 (en) 2016-12-27 2019-08-06 Intel Corporation Secure memory
US10896267B2 (en) * 2017-01-31 2021-01-19 Hewlett Packard Enterprise Development Lp Input/output data encryption
WO2019000456A1 (en) * 2017-06-30 2019-01-03 华为技术有限公司 Data mask transmission method, memory controller, memory chip, and computer system
CN109286564B (en) * 2017-07-20 2022-06-07 迈普通信技术股份有限公司 Message forwarding method and device
KR102410021B1 (en) * 2017-11-20 2022-06-21 에스케이하이닉스 주식회사 Memory system having memory controller and memory module and method of processing data in the memory system
CN109840876B (en) * 2017-11-24 2023-04-18 成都海存艾匹科技有限公司 Graphic memory with rendering function
CN108595459B (en) * 2017-12-30 2022-02-15 北京百度网讯科技有限公司 Relationship index updating method and device and electronic equipment
EP3746925A1 (en) 2018-02-02 2020-12-09 The Charles Stark Draper Laboratory Inc. Systems and methods for policy execution processing
US10416899B2 (en) * 2018-02-13 2019-09-17 Tesla, Inc. Systems and methods for low latency hardware memory management
CN108446081B (en) * 2018-04-11 2019-06-21 杭州旗捷科技有限公司 Consumable chip, consumptive material, consumptive material communication means
JP2020047325A (en) 2018-09-18 2020-03-26 キオクシア株式会社 Semiconductor storage device
CN109635504B (en) * 2019-01-04 2023-04-21 广东智科电子股份有限公司 Heat pump control system software design method
CN110516775B (en) * 2019-07-11 2023-07-25 西安邮电大学 User secret information hiding method based on QR code
CN110719129B (en) * 2019-10-14 2020-06-23 沈阳市电信规划设计院股份有限公司 Point location correction system based on communication basic resource intelligent management data
US11456855B2 (en) * 2019-10-17 2022-09-27 Arm Limited Obfuscating data at-transit
TWI809219B (en) * 2019-11-04 2023-07-21 禾瑞亞科技股份有限公司 Stylus and operating method thereof for transmitting electrical signals carrying pressure information
CN112416383A (en) * 2020-01-21 2021-02-26 上海哔哩哔哩科技有限公司 Hot updating method and device for golang program and computer equipment
CN112270153B (en) * 2020-12-15 2021-04-16 鹏城实验室 Waveform acquisition method and device, test equipment and computer readable storage medium
CN114138282B (en) * 2021-11-30 2023-03-31 四川效率源信息安全技术股份有限公司 Method and device for restoring pseudo code of iOS type code
CN114024871B (en) * 2022-01-04 2022-03-22 苏州浪潮智能科技有限公司 Chip verification method, system, computer equipment and readable storage medium

Citations (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4348727A (en) * 1979-01-13 1982-09-07 Nippondenso Co., Ltd. Air-fuel ratio control apparatus
US4829324A (en) * 1987-12-23 1989-05-09 Xerox Corporation Large array thermal ink jet printhead
US5043740A (en) * 1989-12-14 1991-08-27 Xerox Corporation Use of sequential firing to compensate for drop misplacement due to curved platen
US5160403A (en) * 1991-08-09 1992-11-03 Xerox Corporation Precision diced aligning surfaces for devices such as ink jet printheads
US5600354A (en) * 1992-04-02 1997-02-04 Hewlett-Packard Company Wrap-around flex with address and data bus
US5620614A (en) * 1995-01-03 1997-04-15 Xerox Corporation Printhead array and method of producing a printhead die assembly that minimizes end channel damage
US5712669A (en) * 1993-04-30 1998-01-27 Hewlett-Packard Co. Common ink-jet cartridge platform for different printheads
US5724428A (en) * 1995-11-01 1998-03-03 Rsa Data Security, Inc. Block encryption algorithm with data-dependent rotations
US5745130A (en) * 1995-12-11 1998-04-28 Xerox Corporation System for sensing the temperature of a printhead in an ink jet printer
US5777637A (en) * 1992-03-11 1998-07-07 Rohm Co., Ltd. Nozzle arrangement structure in ink jet print head
US5808635A (en) * 1996-05-06 1998-09-15 Xerox Corporation Multiple die assembly printbar with die spacing less than an active print length
US6281908B1 (en) * 1999-04-15 2001-08-28 Lexmark International, Inc. Alignment system and method of compensating for skewed printing in an ink jet printer
US6324645B1 (en) * 1998-08-11 2001-11-27 Verisign, Inc. Risk management for public key management infrastructure using digital certificates
US6350004B1 (en) * 1998-07-29 2002-02-26 Lexmark International, Inc. Method and system for compensating for skew in an ink jet printer
US6367903B1 (en) * 1997-02-06 2002-04-09 Hewlett-Packard Company Alignment of ink dots in an inkjet printer
US6412903B1 (en) * 2000-09-30 2002-07-02 Samsung Electronics Co., Ltd. Method of correcting a print error caused by misalignment between chips mounted on an array head of an inkjet printer
US6457806B2 (en) * 1999-12-22 2002-10-01 Hewlett-Packard Company Ink-jet print pass microstepping
US20020169971A1 (en) * 2000-01-21 2002-11-14 Tomoyuki Asano Data authentication system
US6547367B1 (en) * 1999-06-07 2003-04-15 Canon Kabushiki Kaisha Ink jet printing apparatus and a judgement method of an ink ejection state of an ink jet head
US6554387B1 (en) * 1999-07-08 2003-04-29 Seiko Epson Corporation Misregistration correction for bidirectional printing in consideration of inclination of nozzle array
US6623106B2 (en) * 2000-03-02 2003-09-23 Silverbrook Research Pty Ltd Overlapping printhead module array configuration
US6652052B2 (en) * 1997-07-15 2003-11-25 Silverbrook Research Pty Ltd Processing of images for high volume pagewidth printing
US20030233548A1 (en) * 2002-06-13 2003-12-18 Christophe Moreaux Authentication of an electronic tag
US20040101142A1 (en) * 2001-07-05 2004-05-27 Nasypny Vladimir Vladimirovich Method and system for an integrated protection system of data distributed processing in computer networks and system for carrying out said method
US6779871B1 (en) * 2003-03-24 2004-08-24 Fuji Xerox Co., Ltd. Inkjet recording head and inkjet recording device
US6830314B2 (en) * 2002-06-11 2004-12-14 Brother Kogyo Kabushiki Kaisha Inkjet recording apparatus
US20050005112A1 (en) * 2000-02-21 2005-01-06 Someren Nicko Van Controlling access to a resource by a program using a digital signature
US6961852B2 (en) * 2003-06-19 2005-11-01 International Business Machines Corporation System and method for authenticating software using hidden intermediate keys
US20050262321A1 (en) * 2001-02-26 2005-11-24 Yoichiro Iino Information processing apparatus and method, and storage medium
US20060004829A1 (en) * 2004-05-27 2006-01-05 Silverbrook Research Pty Ltd Rolling keys
US6996723B1 (en) * 1999-08-10 2006-02-07 Fuji Xerox Co., Ltd. Data generating apparatus and data verifying apparatus
US20060139681A1 (en) * 2004-05-27 2006-06-29 Silverbrook Research Pty Ltd Use of variant and base keys with three or more entities
US20060143454A1 (en) * 2004-05-27 2006-06-29 Silverbrook Research Pty Ltd Storage of multiple keys in memory
US7092930B2 (en) * 2001-03-29 2006-08-15 Pitney Bowes Inc. Architecture and method to secure database records from tampering in devices such as postage value dispensing mechanisms
US20060294312A1 (en) * 2004-05-27 2006-12-28 Silverbrook Research Pty Ltd Generation sequences
US20070083491A1 (en) * 2004-05-27 2007-04-12 Silverbrook Research Pty Ltd Storage of key in non-volatile memory
US7243193B2 (en) * 2004-05-27 2007-07-10 Silverbrook Research Pty Ltd Storage of program code in arbitrary locations in memory
US7243240B2 (en) * 2002-07-26 2007-07-10 Hon Hai Precision Ind. Co., Ltd. System and method for firmware authentication
US7252353B2 (en) * 2004-05-27 2007-08-07 Silverbrook Research Pty Ltd Printer controller for supplying data to a printhead module having one or more redundant nozzle rows
US7266661B2 (en) * 2004-05-27 2007-09-04 Silverbrook Research Pty Ltd Method of storing bit-pattern in plural devices
US7267417B2 (en) * 2004-05-27 2007-09-11 Silverbrook Research Pty Ltd Printer controller for supplying data to one or more printheads via serial links
US7281777B2 (en) * 2004-05-27 2007-10-16 Silverbrook Research Pty Ltd Printhead module having a communication input for data and control
US7314261B2 (en) * 2004-05-27 2008-01-01 Silverbrook Research Pty Ltd Printhead module for expelling ink from nozzles in groups, alternately, starting at outside nozzles of each group
US7465016B2 (en) * 2004-05-27 2008-12-16 Silverbrook Research Pty Ltd Inkjet printhead having modules with displaced inkjet rows
US7607757B2 (en) * 2004-05-27 2009-10-27 Silverbrook Research Pty Ltd Printer controller for supplying dot data to at least one printhead module having faulty nozzle
US7631190B2 (en) * 2004-05-27 2009-12-08 Silverbrook Research Pty Ltd Use of variant and base keys with two entities

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0674993A3 (en) 1994-03-31 1997-06-25 Hewlett Packard Co System, control circuit and method for electronic correction of pen misalignment in ink jet printers.
ES2265673T3 (en) 1999-02-18 2007-02-16 Hewlett-Packard Company A Delaware Corporation A SYSTEM OF CORRECTION OF ERRORS OF POSITIONING OF THE GOTITAS IN THE AXIS OF EXPLORATION IN PRINTERS OF INK BLACK.

Patent Citations (48)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4348727A (en) * 1979-01-13 1982-09-07 Nippondenso Co., Ltd. Air-fuel ratio control apparatus
US4829324A (en) * 1987-12-23 1989-05-09 Xerox Corporation Large array thermal ink jet printhead
US5043740A (en) * 1989-12-14 1991-08-27 Xerox Corporation Use of sequential firing to compensate for drop misplacement due to curved platen
US5160403A (en) * 1991-08-09 1992-11-03 Xerox Corporation Precision diced aligning surfaces for devices such as ink jet printheads
US5777637A (en) * 1992-03-11 1998-07-07 Rohm Co., Ltd. Nozzle arrangement structure in ink jet print head
US5600354A (en) * 1992-04-02 1997-02-04 Hewlett-Packard Company Wrap-around flex with address and data bus
US5712669A (en) * 1993-04-30 1998-01-27 Hewlett-Packard Co. Common ink-jet cartridge platform for different printheads
US5620614A (en) * 1995-01-03 1997-04-15 Xerox Corporation Printhead array and method of producing a printhead die assembly that minimizes end channel damage
US5724428A (en) * 1995-11-01 1998-03-03 Rsa Data Security, Inc. Block encryption algorithm with data-dependent rotations
US5745130A (en) * 1995-12-11 1998-04-28 Xerox Corporation System for sensing the temperature of a printhead in an ink jet printer
US5808635A (en) * 1996-05-06 1998-09-15 Xerox Corporation Multiple die assembly printbar with die spacing less than an active print length
US6367903B1 (en) * 1997-02-06 2002-04-09 Hewlett-Packard Company Alignment of ink dots in an inkjet printer
US6652052B2 (en) * 1997-07-15 2003-11-25 Silverbrook Research Pty Ltd Processing of images for high volume pagewidth printing
US6350004B1 (en) * 1998-07-29 2002-02-26 Lexmark International, Inc. Method and system for compensating for skew in an ink jet printer
US6324645B1 (en) * 1998-08-11 2001-11-27 Verisign, Inc. Risk management for public key management infrastructure using digital certificates
US6281908B1 (en) * 1999-04-15 2001-08-28 Lexmark International, Inc. Alignment system and method of compensating for skewed printing in an ink jet printer
US6547367B1 (en) * 1999-06-07 2003-04-15 Canon Kabushiki Kaisha Ink jet printing apparatus and a judgement method of an ink ejection state of an ink jet head
US6554387B1 (en) * 1999-07-08 2003-04-29 Seiko Epson Corporation Misregistration correction for bidirectional printing in consideration of inclination of nozzle array
US6996723B1 (en) * 1999-08-10 2006-02-07 Fuji Xerox Co., Ltd. Data generating apparatus and data verifying apparatus
US6457806B2 (en) * 1999-12-22 2002-10-01 Hewlett-Packard Company Ink-jet print pass microstepping
US20020169971A1 (en) * 2000-01-21 2002-11-14 Tomoyuki Asano Data authentication system
US20050005112A1 (en) * 2000-02-21 2005-01-06 Someren Nicko Van Controlling access to a resource by a program using a digital signature
US6623106B2 (en) * 2000-03-02 2003-09-23 Silverbrook Research Pty Ltd Overlapping printhead module array configuration
US6412903B1 (en) * 2000-09-30 2002-07-02 Samsung Electronics Co., Ltd. Method of correcting a print error caused by misalignment between chips mounted on an array head of an inkjet printer
US20050262321A1 (en) * 2001-02-26 2005-11-24 Yoichiro Iino Information processing apparatus and method, and storage medium
US7092930B2 (en) * 2001-03-29 2006-08-15 Pitney Bowes Inc. Architecture and method to secure database records from tampering in devices such as postage value dispensing mechanisms
US20040101142A1 (en) * 2001-07-05 2004-05-27 Nasypny Vladimir Vladimirovich Method and system for an integrated protection system of data distributed processing in computer networks and system for carrying out said method
US6830314B2 (en) * 2002-06-11 2004-12-14 Brother Kogyo Kabushiki Kaisha Inkjet recording apparatus
US20030233548A1 (en) * 2002-06-13 2003-12-18 Christophe Moreaux Authentication of an electronic tag
US7243240B2 (en) * 2002-07-26 2007-07-10 Hon Hai Precision Ind. Co., Ltd. System and method for firmware authentication
US6779871B1 (en) * 2003-03-24 2004-08-24 Fuji Xerox Co., Ltd. Inkjet recording head and inkjet recording device
US6961852B2 (en) * 2003-06-19 2005-11-01 International Business Machines Corporation System and method for authenticating software using hidden intermediate keys
US7266661B2 (en) * 2004-05-27 2007-09-04 Silverbrook Research Pty Ltd Method of storing bit-pattern in plural devices
US7252353B2 (en) * 2004-05-27 2007-08-07 Silverbrook Research Pty Ltd Printer controller for supplying data to a printhead module having one or more redundant nozzle rows
US20060294312A1 (en) * 2004-05-27 2006-12-28 Silverbrook Research Pty Ltd Generation sequences
US20070083491A1 (en) * 2004-05-27 2007-04-12 Silverbrook Research Pty Ltd Storage of key in non-volatile memory
US7267417B2 (en) * 2004-05-27 2007-09-11 Silverbrook Research Pty Ltd Printer controller for supplying data to one or more printheads via serial links
US20060143454A1 (en) * 2004-05-27 2006-06-29 Silverbrook Research Pty Ltd Storage of multiple keys in memory
US20060004829A1 (en) * 2004-05-27 2006-01-05 Silverbrook Research Pty Ltd Rolling keys
US20060139681A1 (en) * 2004-05-27 2006-06-29 Silverbrook Research Pty Ltd Use of variant and base keys with three or more entities
US7243193B2 (en) * 2004-05-27 2007-07-10 Silverbrook Research Pty Ltd Storage of program code in arbitrary locations in memory
US7281777B2 (en) * 2004-05-27 2007-10-16 Silverbrook Research Pty Ltd Printhead module having a communication input for data and control
US7314261B2 (en) * 2004-05-27 2008-01-01 Silverbrook Research Pty Ltd Printhead module for expelling ink from nozzles in groups, alternately, starting at outside nozzles of each group
US7465016B2 (en) * 2004-05-27 2008-12-16 Silverbrook Research Pty Ltd Inkjet printhead having modules with displaced inkjet rows
US7524007B2 (en) * 2004-05-27 2009-04-28 Silverbrook Research Pty Ltd Printhead having sequenced nozzle firing
US7557941B2 (en) * 2004-05-27 2009-07-07 Silverbrook Research Pty Ltd Use of variant and base keys with three or more entities
US7607757B2 (en) * 2004-05-27 2009-10-27 Silverbrook Research Pty Ltd Printer controller for supplying dot data to at least one printhead module having faulty nozzle
US7631190B2 (en) * 2004-05-27 2009-12-08 Silverbrook Research Pty Ltd Use of variant and base keys with two entities

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009145775A1 (en) * 2008-05-29 2009-12-03 Hewlett-Packard Development Company, L.P. Replaceable printer component including a memory storing a tag encryption mask
US20110176175A1 (en) * 2008-05-29 2011-07-21 Panshin Stephen D Replaceable Printer Component Including a Memory Storing a Tag Encryption Mask
US9707784B2 (en) 2008-05-29 2017-07-18 Hewlett-Packard Development Company, L.P. Replaceable printer component
US9707783B2 (en) 2008-05-29 2017-07-18 Hewlett-Packard Development Company, L.P. Replaceable printer component including a memory storing a tag encryption mask
WO2012174169A2 (en) * 2011-06-13 2012-12-20 STMicroelectronics Asia Pacific Pte. Ltd. (Singapore) Delaying or deterring counterfeiting and/or cloning of a component
WO2012174169A3 (en) * 2011-06-13 2013-04-25 STMicroelectronics Asia Pacific Pte. Ltd. (Singapore) Delaying or deterring counterfeiting and/or cloning of a component
US9536112B2 (en) 2011-06-13 2017-01-03 Stmicroelectronics Asia Pacific Pte Ltd. Delaying or deterring counterfeiting and/or cloning of a component
US8864277B2 (en) 2011-09-30 2014-10-21 Hewlett-Packard Development Company, L.P. Authentication systems and methods

Also Published As

Publication number Publication date
US7243193B2 (en) 2007-07-10
US20060132822A1 (en) 2006-06-22

Similar Documents

Publication Publication Date Title
US7953982B2 (en) Method of authenticating digital signature
US7986439B2 (en) Resource entity using resource request entity for verification
US20070211292A1 (en) Method Of Storing Code Segements In Plural Printer Cartridges
US20070211291A1 (en) Method Of Storing Bit-Pattern In Plural Printer Cartridges
US20100250942A1 (en) System for enabling authenticated communication between entities
US7747646B2 (en) System having secure access between IC entities
US7246098B1 (en) Consumable authentication protocol and system
US7454617B2 (en) Apparatus for validating the presence of an authorized accessory
US8370260B2 (en) Printing system for validating printing consumable
US7194629B2 (en) Apparatus for authenticating memory space of an authorized accessory
US7657488B2 (en) Validating apparatus having encryption integrated circuits
US7962767B2 (en) Integrated circuit having obscured state change circuitry
US20090319802A1 (en) Key Genaration In An Integrated Circuit
US7093139B2 (en) Unauthorized modification of values stored in flash memory
US20100250971A1 (en) Printer consumable comprising integrated circuit protected from power supply attacks
US20100213878A1 (en) Method and apparatus for reducing optical emissions in an integrated circuit
US7346586B1 (en) Validation protocol and system

Legal Events

Date Code Title Description
AS Assignment

Owner name: SILVERBROOK RESEARCH PTY LTD, AUSTRALIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:WALMSLEY, SIMON ROBERT;REEL/FRAME:019298/0729

Effective date: 20070508

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION

AS Assignment

Owner name: ZAMTEC LIMITED, IRELAND

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SILVERBROOK RESEARCH PTY. LIMITED AND CLAMATE PTY LIMITED;REEL/FRAME:028483/0085

Effective date: 20120503