Patent Description:
Relevant prior art in the field is represented by the following patent publications: <CIT>, <CIT> and <CIT>.

In the following descriptiion and figures, some example implementations of methods of encryption, methods of decryption, and devices capable of using such methods of encryption and/or decryption are described. Some print solutions are vulnerable to attacks, such as man-in-the-middle attacks, where an adversary can spoof the identity of a print apparatus and read a confidential document. Transport security mechanisms may provide authenticated, end-to-end encryption of print jobs, whereas some print workflows, such as pull printing or cloud-based printing, do not allow the user to connect directly to a print apparatus. As a result, the user may not know where the job is sent or how the job is handled by intermediary services. In some examples, print jobs may be encrypted using a password-derived symmetric encryption key, but such jobs may be vulnerable to undetected manipulation of the encrypted print job and/or interception of the print job followed by decryption (e.g., when the password is weak or discovered by an adversary).

Various examples described below relate to encrypting a document using a first form of encryption to protect the content under a release policy and a second form of encryption using a printer-based information. For example, an electronic document for printing may be protected with a user password (or other user-specific information) and restricted to being printed by a specific print apparatus, such as by limitations using public-key cryptography with the print apparatus or via another device performing cryptographic operations. By binding the electronic document in a dually protective manner, a print job is released when multiple conditions are met, and attacks isolated to a user or a printer may be prevented, for example.

<FIG> is a block diagram depicting an example encryption system <NUM>. The example encryption system <NUM> of <FIG> generally includes an encryption engine <NUM> and a communication engine <NUM>. In general, the encryption engine <NUM> uses multiple encryption techniques to protect data including a wrapping technique using input <NUM> for generating a key encryption key (KEK) and an encryption technique using a printer public key <NUM>, and the communication engine <NUM> may prepare transmission of a file encrypted by the encryption engine <NUM>.

The encryption engine <NUM> represents any circuitry or combination of circuitry and executable instructions to wrap a key using a key wrapping technique that utilizes a KEK and to encrypt a key using a printer public key <NUM>. The encryption engine <NUM> uses unique print job data (i.e., the KEK input <NUM>) and unique printer data to protect the print job. The encryption engine <NUM> may generate an electronic package of data encrypted using the unique print job data and the unique printer data such that the print job is protected by multiple security vectors. The KEK input <NUM> and the printer public key <NUM> may be locally stored with the encryption system <NUM> or may be retrievable from a remote storage.

In an example, the encryption engine <NUM> may be a combination of circuitry and executable instructions to generate a KEK using a passphrase provided by a user and use a key wrapping technique to wrap data, such as a content key, using the generated KEK. As used herein, the KEK is a combination of characters derived from user-associated data or policy-associated data. The user-associated data or policy-associated data is represented in <FIG> as KEK input <NUM>. As used herein, user-associated data may be any appropriate data provided by a user or correspond to a user profile. Example user-associated data includes a user-provided passphrase (e.g., a password) or biometric data, a centrally-stored personal identification number (PIN), unique data stored with the user profile (such as an Active Directory file), and the like. As used herein, the policy-associated data may be any appropriate data corresponding to a release policy for printing a print job. Example policy-associated data includes location-based information (such as a geographic region, an Internet Protocol (IP) address, a Media Access Control (MAC) address list, or building category), time-based information (such as range of hours to perform the print job), group-based information (such as restrictions to a security level, a role, a specific team or department, the executive committee or board members, etc.), process-based information (such as a maximum number of copies, whether color reproduction is allowed, page size restrictions, workflow limitations, or any other data corresponding to how the document is to be processed) and the like.

The encryption engine <NUM> may include circuity or a combination of circuitry and executable instructions to generate a plurality of keys. For example, the encryption engine <NUM> may include a combination of circuitry and executable instructions to generate a content encryption key (CEK) to use for content of an electronic document, encrypt content using the CEK, generate a KEK from user-associated data or policy-associated data, wrap the CEK based on a key wrap operation using the KEK, generate a policy encryption key (PEK), encrypt the wrapped CEK using the PEK, and encrypt the PEK using a public key corresponding to a print apparatus. Keys, such as the CEK and PEK, are a combination of characters (such as letters, numbers, and/or symbols) useable as a parameter that determines the functional output of a cryptographic algorithm. As used herein, a wrapping operation represents an encryption operation with authentication. In this manner, a wrapping operation may encrypt a content encryption key using the key encryption key in a manner that allows for the wrapped key generated from the wrapping operation to be authenticated.

The encryption engine <NUM> may include circuitry or a combination of circuitry and executable instructions to generate a policy object. A policy object, as used herein, is a data structure with storage variables that represent values corresponding to policy parameters (e.g., settings and/or rules). For example, the policy object may include a release policy for specific data (e.g., a particular document or print job) that includes a number of permissions and a number of rules and/or conditions for printing the specific data. For example, the policy object may include a wrapped key, print job information including a subject or title of a print job, parameters and printing limitations as set by a rule, other restrictions, a nonce (discussed further below), and the like. The policy object may be a package of separate data, such as separately encrypted data.

The policy object may be encrypted in way preferable for the size of the policy object. For example, the header of the policy object may be encrypted asymmetrically while the payload of the policy object is encrypted symmetrically. As another example, hybrid encryption may be used to encrypt the policy object. The encryption engine <NUM> may encrypt the policy object using a PEK that is different from the CEK, KEK, and the public key of the destination print apparatus. In that example, the encryption engine <NUM> may encrypt the PEK with the public key of the destination print apparatus and provide the encrypted PEK with the policy object encrypted with the PEK to reduce the size of the payload provided to the print apparatus.

The encryption engine <NUM> may generate a nonce and include the nonce in the policy object. A nonce, as used herein, represents a unique set of characters. The nonce may be used to ensure authentication of the print job. For example, the encryption engine <NUM> may generate a random nonce for a policy object that may be verified by the print apparatus, thus a repeated nonce may indicate an intercepted print job. In this manner, a randomly generated nonce may allow for improved authentication and avoid potential attacks to confidential data, for example.

The communication engine <NUM> represents any circuitry or combination of circuitry and executable instructions to prepare a file encrypted by the encryption engine <NUM> to a print apparatus corresponding to the printer public key <NUM>. For example, the communication engine <NUM> may include a combination of circuitry and executable instructions to send a first cipher corresponding to the encrypted policy object and a second cipher corresponding to the encrypted policy encryption key to the print apparatus.

The encryption system <NUM> may be implemented as an intermediary between a user device and the destination print apparatus. In such an example, the communication engine <NUM> may be implemented as part of a print server to receive an electronic file encrypted with a public key of a print server and the encryption engine <NUM> decrypts the electronic file to recover the policy object using service-specific information (e.g., a printer server public key), the encryption engine <NUM> selects the print apparatus from a printer group identified by the print server based on a retrieval request (e.g., a pull request to a specific printer), the encryption engine <NUM> encrypts the policy object using the public key of the selected print apparatus, and the communication engine <NUM> sends the re-encrypted policy object to the selected print apparatus. Such an example is discussed further with respect to <FIG>. In some examples, functionalities described herein in relation to any of <FIG> may be provided in combination with functionalities described herein in relation to any of <FIG>,.

<FIG> is a block diagram depicting an example decryption system <NUM>. The example decryption system <NUM> of <FIG> generally includes decryption engine <NUM> and a print engine <NUM>. In general, the decryption engine <NUM> decrypts a cipher <NUM> via a technique using the printer private key <NUM> and the print engine <NUM> prepares an electronic file recovered via the decryption engine <NUM> to be printed by a print apparatus.

The decryption engine <NUM> represents any circuitry or combination of circuitry and executable instructions to recover a wrapped key using a key corresponding to a print apparatus and unwrapping a key to recover a CEK usable to decrypt content. For example, the decryption engine <NUM> may include a combination of circuitry and executable instructions to recover a policy object using a private key corresponding to a print apparatus, generate a key encryption key using user-associated information or policy-associated information, unwrap a wrapped key of the policy object using the key encryption key to recover a content encryption key, and decrypting an encrypted electronic document using the content encryption key.

The decryption engine <NUM> may decrypt multiple keys in the process of decrypting an electronic document. For example, the decryption engine <NUM> may decrypt a package using a printer private key <NUM> to obtain the cipher <NUM>. For another example, the cipher <NUM> may be a key cipher <NUM> that is decryptable using the printer private key <NUM>. The cipher <NUM> and the printer private key <NUM> may be stored locally on the decryption system <NUM>. In other examples, the cipher <NUM> may be retrieved remotely.

The decryption engine <NUM> may recover a policy object via a decryption technique and unwrap a key (i.e., decrypt a key with an authentication operation). For example, the decryption engine <NUM> may include a combination of circuitry and executable instruction to decrypt a key cipher using a private key corresponding to the print apparatus to recover a PEK, decrypt a policy cipher using the PEK to recover a policy object, unwrap a wrapped key located within the policy object using a KEK generated from user-provided information to recover a CEK, and decrypt an encrypted electronic document using the CEK.

The decryption engine <NUM> may perform further authentication operations. For example, the decryption engine <NUM> may include a combination of circuitry and executable instructions to retrieve a number of reference nonces from a storage medium coupled to the print apparatus, compare a nonce of a print job corresponding to the policy object to the number of references nonces retrieved from the storage medium. In that example, the decryption engine <NUM> may delete the print job in response to identification of a replayed nonce corresponding to the print job or may proceed with decrypting and/or performing a print operation.

The decryption engine <NUM> may cause components of a print apparatus to perform actions, such as operations corresponding to printing a document. For example, the decryption engine <NUM> may include a combination of circuitry and executable instructions to cause a display engine to display a prompt for a password corresponding to the KEK in response to a job selection of the list of available print jobs, cause a display engine to display a list of available print jobs for the print apparatus, and/or cause a display engine to display an error message in response to a request to print the print job outside of the rule or a parameter corresponding to the policy object.

The print engine <NUM> represents any circuitry or combination of circuitry and executable instructions to perform a print operation according to a release policy. For example, the print engine <NUM> may include a combination of circuitry and executable instructions to operate the print apparatus according to a rule of the policy object and print the decrypted electronic document when the rule of the policy is satisfied. In this manner, the print engine <NUM> may restrict performing a print operation until restrictions are met and the user and/or policy are verified as authorized.

<FIG> is a block diagram depicting transfer of encrypted documents between an example encryption system <NUM> implemented on a user device <NUM> and an example decryption system <NUM> implemented on a print apparatus <NUM>. In the example of <FIG>, the user device <NUM> provides a content cipher <NUM>, a key cipher <NUM>, and a policy cipher <NUM> to a print apparatus <NUM> to be decrypted when appropriately authorized as defined by the policy object (e.g., based on the policy rule <NUM>). As used herein, a content cipher is a cipher derived from encrypting content, a policy cipher is a cipher derived from encrypting the policy object, and a key cipher is a cipher derived from encrypting a key. In the example of <FIG>, the key cipher <NUM> is a cipher derived from encrypting the PEK using the public key <NUM> of the print apparatus <NUM>.

The encryption system <NUM> of the user device <NUM> generally includes an encryption engine <NUM>, a communication engine <NUM>, and a display engine <NUM>. The decryption system <NUM> of the print apparatus <NUM> generally includes a decryption engine <NUM>, a print engine <NUM>, and a display engine <NUM>. The encryption engine <NUM>, the communication engine <NUM>, the decryption engine <NUM>, and the print engine <NUM> represent the same as the encryption engine <NUM> of <FIG>, the communication engine <NUM> of <FIG>, the decryption engine <NUM> of <FIG>, and the print engine <NUM> of <FIG>, respectively, and their descriptions are not repeated for brevity. The display engines <NUM> and <NUM> represent a combination of a display, circuitry, and executable instructions to present an image on the display. The display engines <NUM> and <NUM> may be user interfaces to allow for input to be provided by and/or presented to a user. For example, the display engine <NUM> may include a control panel that displays a user information request, such as a passphrase request to be used as input for generating a KEK. For another example, the display engine <NUM> may cause a display to present a list of available print jobs corresponding to a user. In yet another example, the display engine <NUM> may cause a display to present an error message in response to a request to print a job outside of the release policy (e.g., not in accordance with a rule or parameter defined by a policy object of the print job).

As shown in <FIG>, the engines <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> may be integrated into a compute device, such as a user device or a print apparatus. The engines <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> may be integrated via circuitry or as installed instructions into a memory resource of the compute device. In other examples, the engines may be distributed across devices.

The user device <NUM> represents generally any compute device to communicate a network request and receive and/or process the corresponding responses. For example, a browser application may be installed on the user device <NUM> to receive the network packet from another device (e.g., a web server) and utilize the payload of the packet to display an element of a page via the browser application.

In examples described herein, a "print apparatus" may be a device to print content on a physical medium (e.g., paper, textiles, a layer of powder-based build material, etc.) with a print material (e.g., ink or toner). For example, the print apparatus may be a wide-format print apparatus that prints latex-based print fluid on a print medium, such as a print medium that is size A2 or larger. In some examples, the physical medium printed on may be a web roll or a pre-cut sheet. In the case of printing on a layer of powder-based build material, the print apparatus may utilize the deposition of print materials in a layer-wise additive manufacturing process. A print apparatus may utilize suitable print consumables, such as ink, toner, fluids or powders, or other raw materials for printing. In some examples, a print apparatus may be a three-dimensional (3D) print apparatus. An example of fluid print material is a water-based latex ink ejectable from a print head, such as a piezoelectric print head or a thermal inkjet print head. Other examples of print fluid may include dye-based color inks, pigment-based inks, solvents, gloss enhancers, fixer agents, and the like.

The compute devices <NUM> and <NUM> may include data stores (such as data stores <NUM> and <NUM>) to contain information useable by the systems discussed herein, The compute devices <NUM> and <NUM> may include user interfaces (such as a display or a keyboard) to receive or provide information to a user. The compute devices <NUM> and <NUM> may include electronic interfaces (such as a network card or wireless transceiver) to provide information among devices. The compute devices may be electrically linked via the electronic interfaces. A link between devices represents one or a combination of a cable, wireless connection, fiber optic connection, or remote connections via a telecommunications link, an infrared link, a radio frequency link, or any other connectors of systems that provide electronic communication. The link may include, at least in part, intranet, the Internet, or a combination of both. The link may also include intermediate proxies, routers, switches, load balancers, and the like.

The data store <NUM> may include data useable with the encryption system <NUM> and the data store <NUM> may include data useable with the decryption system <NUM>. For example, the data store <NUM> of <FIG> includes the printer public key <NUM>, input <NUM> provided by a user, a selection <NUM> of a policy rule and/or parameter for a print job, etc. For another example, the data store <NUM> may include a printer private key <NUM>, a policy rule <NUM>, a print parameter <NUM>, etc. In some examples, the data stores <NUM> and <NUM> may be the same data store or distributed among a number of data stores. A data store may be a memory resource as discussed herein.

<FIG> is a block diagram depicting transfer of encrypted documents between an example encryption system <NUM> implemented on a user device <NUM> and an example decryption system <NUM> implemented on a print apparatus <NUM> via secure transfer system <NUM> implemented on an example print service <NUM>, In the example of <FIG>, the encryption system <NUM> of the user device <NUM> generates a service cipher package <NUM> encrypted for authorization using a service public key <NUM> to restrict decryption to the print server <NUM>.

The print server <NUM> includes an encryption and decryption system (e.g., the secure transfer system <NUM>) that includes a decryption engine <NUM>, a group engine <NUM>, an encryption engine <NUM>, a communication engine <NUM>, and a data store <NUM>. The decryption engine <NUM>, the encryption engine <NUM>, and the communication <NUM> are similar to the decryption engine <NUM>, the encryption engine <NUM>, and the communication engine <NUM>, respectively. The decryption and encryption system of the print server <NUM> allows for securely routing the print job from the user device to the print apparatus through a service provided by the print server. The decryption engine <NUM> decrypts the service cipher package <NUM> using the server private key <NUM> to obtain the policy object <NUM>. The group engine <NUM> represents circuitry or a combination of circuitry and executable instructions to, using information of the policy object <NUM>, identifies a printer group <NUM> authorized to receive the print job corresponding to the policy object <NUM>. The group engine <NUM> may include circuitry or a combination of circuitry and executable instructions to prepare a number of packages to be encrypted and passed to printers of the printer group via the communication engine <NUM>. The encryption engine <NUM> performs the encryption of the policy object <NUM> using the printer private key for each print apparatus of the printer group to which the communication engine <NUM> is going to send. In this manner, the printer cipher package <NUM> is securely encrypted using the printer public key <NUM> such that the decryption system of the print apparatus <NUM> is able to decrypt the printer cipher package <NUM> using the printer private key <NUM>.

The service device <NUM> represents generally any compute device(s) to respond to a network request received from a user device <NUM>, whether virtual or real. For example, the service device <NUM> may operate a combination of circuitry and executable instructions to provide a network packet in response to a request for a page or functionality of an application.

The compute devices <NUM>, <NUM>, and <NUM> may be located on separate networks or part of the same network. An example computing environment may include any appropriate number of networks and any number of the networks may include a cloud compute environment. A cloud compute environment may include a virtual shared pool of compute resources, such as a distributed network comprising virtual computing resources. Any appropriate combination of the systems <NUM>, <NUM>, <NUM>, and compute devices <NUM>, <NUM>, and <NUM> may be a virtual instance of a resource of a virtual shared pool of resources. The engines and/or modules of the system <NUM> herein may reside and/or execute "on the cloud" (e.g., reside and/or execute on a virtual shared pool of resources).

<FIG> is a block diagram depicting an example encryption system <NUM>. <FIG> is a block diagram depicting an example decryption system <NUM>. <FIG> depict that the example systems <NUM> and <NUM> may comprise a memory resource <NUM> and <NUM> operatively coupled to a processor resource <NUM> and <NUM> respectively. The memory resources <NUM> and <NUM> may contain a set of instructions that are executable by the processor resource <NUM> and <NUM> respectively. The memory resources <NUM> and <NUM> may also contain data useable by the systems <NUM> and <NUM>, such as the printer public key <NUM> and the printer private key <NUM>.

The set of instructions of memory resource <NUM> are operable to cause the processor resource <NUM> to perform operations of the system <NUM> when the set of instructions are executed by the processor resource <NUM>. The set of instructions stored on the memory resource <NUM> may be represented as an encryption module <NUM>, a communication module <NUM>, and a display module <NUM>. The encryption module <NUM>, the communication module <NUM>, and the display module <NUM> represent program instructions that when executed cause function of the encryption engine <NUM>, the communication engine <NUM>, and the display engine <NUM> of <FIG>, respectively. The processor resource <NUM> may carry out a set of instructions to execute the modules <NUM>, <NUM>, <NUM>, and/or any other appropriate operations among and/or associated with the modules of the system <NUM>. For example, the processor resource <NUM> may carry out a set of instructions to generate a KEK from user-associated data or policy-associated data, encrypt a CEK using the KEK to generate a wrapped key, generate a policy object that includes the wrapped key, encrypt the policy object with a PEK, and encrypt the PEK using a public key of a print apparatus. For another example, the processor resource <NUM> may carry out a set of instructions to encrypt content using the CEK, randomly generate a nonce, generate a wrapped key using a KEK based on user input, package the wrapped key, print job information, and the nonce into a policy object, encrypt the policy object using the PEK, encrypt the PEK using a public key of a print apparatus, and send a first cipher corresponding to the encrypted policy object and a second cipher corresponding to the encrypted PEK to the print apparatus. In yet another example, the processor resource <NUM> may carry out a set of instructions to receive an electronic file encrypted with a public key of a print server, unwrap the electronic file to recover the policy object, select a print apparatus from a printer group identified by the print server based on a retrieval request, and rewrap the policy object with a public key of a print apparatus.

The set of instructions of memory resource <NUM> are operable to cause the processor resource <NUM> to perform operations of the system <NUM> when the set of instructions are executed by the processor resource <NUM>. The set of instructions stored on the memory resource <NUM> may be represented as a decryption module <NUM>, a communication module <NUM>, and a display module <NUM>. The decryption module <NUM>, the communication module <NUM>, and the display module <NUM> represent program instructions that when executed cause function of the decryption engine <NUM>, the communication engine <NUM>, and the display engine <NUM> of <FIG>, respectively. The processor resource <NUM> may carry out a set of instructions to execute the modules <NUM>, <NUM>, <NUM>, and/or any other appropriate operations among and/or associated with the modules of the system <NUM>. For example, the processor resource <NUM> may carry out a set of instructions to cause a control panel to display a user information request, decrypt a key cipher using a private key corresponding to a print apparatus to recover a PEK, decrypt a policy cipher using the PEK to recover a policy object with a wrapped key, unwrap the wrapped key using a KEK generated from user-provided information to recover a CEK, decrypt an encrypted electronic document using the CEK, operate a print apparatus according to a rule of the policy object, and print the decrypted electronic document when the rule of the policy object is satisfied. For another example, the processor resource <NUM> may carry out a set of instructions to cause the display engine to display a list of available print jobs for the print apparatus, retrieve a number of nonces from a storage medium coupled to the print apparatus, compare a nonce of a print job corresponding to the policy object to the number of nonces retrieved from the storage medium, delete the print job in response to identification of a replayed nonce corresponding to the print job, cause the display engine to display a prompt for a password corresponding to the KEK in response to a job selection of the list of available print jobs, and cause the display engine to display an error message in response to a request to print the print job outside of the rule or a parameter corresponding to the policy object.

Although these particular modules and various other modules are illustrated and discussed in relation to <FIG> and other example implementations, other combinations or sub-combinations of modules may be included within other implementations, Said differently, although the modules illustrated in <FIG> and discussed in other example implementations perform specific functionalities in the examples discussed herein, these and other functionalities may be accomplished, implemented, or realized at different modules or at combinations of modules. For example, two or more modules illustrated and/or discussed as separate may be combined into a module that performs the functionalities discussed in relation to the two modules. As another example, functionalities performed at one module as discussed in relation to these examples may be performed at a different module or different modules.

A processor resource is any appropriate circuitry capable of processing (e.g., computing) instructions, such as one or multiple processing elements capable of retrieving instructions from a memory resource and executing those instructions. For example, the processor resource <NUM> may be a central processing unit (CPU) that enables encryption by fetching, decoding, and executing modules <NUM>, <NUM>, and <NUM>. For another example, the processor resource <NUM> may be a CPU that enables decryption by fetching, decoding, and executing modules <NUM>, <NUM>, and <NUM>. Example processor resources include at least one CPU, a semiconductor-based microprocessor, a programmable logic device (PLD), and the like. Example PLDs include an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a programmable array logic (PAL), a complex programmable logic device (CPLD), and an erasable programmable logic device (EPLD). A processor resource may include multiple processing elements that are integrated in a single device or distributed across devices. A processor resource may process the instructions serially, concurrently, or in partial concurrence,.

A memory resource represents a medium to store data utilized and/or produced by the systems discussed herein. The data stores discussed herein are memory resources as described below. The medium is any non-transitory medium or combination of non-transitory media able to electronically store data, such as modules and/or data of the systems <NUM> and <NUM>. For example, the medium may be a storage medium, which is distinct from a transitory transmission medium, such as a signal. The medium may be machine-readable, such as computer-readable. The medium may be an electronic, magnetic, optical, or other physical storage device that is capable of containing (i.e., storing) executable instructions. A memory resource may be said to store program instructions that when executed by a processor resource cause the processor resource to implement functionality of the system (e. g, system <NUM> and/or system <NUM>). A memory resource may be integrated in the same device as a processor resource or it may be separate but accessible to that device and the processor resource. A memory resource may be distributed across devices.

In the discussion herein, the engines <NUM> and <NUM> of <FIG>; the engines <NUM> and <NUM> of <FIG>; the engines <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> of <FIG> and <FIG>; the modules <NUM>, <NUM>, and <NUM> of <FIG>; and the modules <NUM>, <NUM>, <NUM> of <FIG> have been described as circuitry or a combination of circuitry and executable instructions. Such components may be implemented in a number of fashions. Looking at <FIG>, the executable instructions may be processor-executable instructions, such as program instructions, stored on the memory resource <NUM>, which is a tangible, non-transitory computer-readable storage medium, and the circuitry may be electronic circuitry, such as processor resource <NUM>, for executing those instructions. The instructions residing on a memory resource may comprise any set of instructions to be executed directly (such as machine code) or indirectly (such as a script) by a processor resource.

In some examples, the systems <NUM> and/or <NUM> may include the executable instructions may be part of an installation package that when installed may be executed by a processor resource to perform operations of the systems <NUM> and/or <NUM>, such as methods described with regards to <FIG>. In that example, a memory resource may be a portable medium such as a compact disc, a digital video disc, a flash drive, or memory maintained by a computer device, such as a printer server <NUM> of <FIG>, from which the installation package may be downloaded and installed. In another example, the executable instructions may be part of an application or applications already installed. A memory resource may be a non-volatile memory resource such as read-only memory (ROM), a volatile memory resource such as random-access memory (RAM), a storage device, or a combination thereof. Example forms of a memory resource include static RAM (SRAM), dynamic RAM (DRAM), electrically erasable programmable ROM (EEPROM), flash memory, or the like. A memory resource may include integrated memory such as a hard drive (HD), a solid-state drive (SSD), or an optical drive.

Referring to <FIG>, the engines and/or the modules may be distributed across devices, such as devices <NUM>, <NUM>, <NUM>, of <FIG>. The engine and/or modules may complete or assist completion of operations performed in describing another engine and/or module. Thus, although the various engines and modules are shown as separate engines in <FIG>, in other implementations, the functionality of multiple engines and/or modules may be implemented as a single engine and/or module or divided in a variety of engines and/or modules. In some example, the engines of the encryption system <NUM> may perform example methods described in connection with <FIG> and the engines of decryption system <NUM> may perform the example methods described in connection with <FIG>.

<FIG> are flow diagrams depicting example methods of encryption. The methods <NUM>, <NUM>, <NUM>, and <NUM> of <FIG> are performable by engines, such as an encryption engine <NUM> of <FIG>. Referring to <FIG>, example method <NUM> of encryption may generally comprise generating a CEK to use for content of an electronic document, generating a KEK from user-associated data or policy-associated data, wrapping the CEK based on a key wrap operation using the KEK, encrypting the wrapped CEK using a PEK, and encrypting the PEK using a public key corresponding to a print apparatus.

At block <NUM>, a CEK is generated. The CEK may be a randomly generated set of characters. At block <NUM>, a KEK is generated. The KEK may be generated at least in part by a user-associated data or policy-associated data. The operations to produce the KEK may be repeatable based on the input data. In this manner, the KEK may be pseudorandom set of characters deterministically generated from a user-associated data or policy-associated data.

At block <NUM>, the CEK is wrapped using the KEK. For example, a key wrapping operation may use the KEK derived from user-associated data or policy-associated data to authentically encrypt the CEK to result in a wrapped CEK. At block <NUM>, the wrapped CEK is encrypted using a PEK. The PEK may be a randomly generated set of characters. At block <NUM>, the PEK is encrypted using a public key corresponding to a print apparatus. In this manner, the symmetric cryptographic technique to encrypt the wrapped CEK with PEK may be kept secret in an asymmetric manner using a unique key corresponding to a print apparatus. In this manner, access to the key needed to retrieve the wrapped CEK is securely limited to the print apparatus, for example.

Referring to <FIG>, example method <NUM> of encryption using a service intermediary may generally comprise unwrapping a package, identifying a printer of a printer group, and rewrapping the package to send to the identified printer. At block <NUM>, a request to provide a print job to a printer group is received. For example, a print server may receive a printer group request with an encrypted package. At block <NUM>, a package encrypted using a public key corresponding to a service address is unwrapped. The unwrapped package may provide a policy object including a wrapped key.

At block <NUM>, a printer of a printer group corresponding to a service at the service address is identified. For example, a single printer may be identified, or a set of printers may be identified, to receive the packaged unwrapped at block <NUM>. At block <NUM>, a number of packages are encrypted. The number of encrypted packages at block <NUM> correspond to a number of printers in the print group identified at block <NUM> to receive the package. For example, an entire group of multiple printers may be selected to receive the package and a number equal to the size of the group of the printers may be encrypted. Thus, a single package may be encrypted when the group of printers is a single printer and a plurality of packages may be encrypted when the group of printers includes more than one printer (and more than one printer is selected to receive the package). At block <NUM>, the package unwrapped at block <NUM> is rewrapped using a public key corresponding to a printer of the printer group. For example, each of the number of packages may be encrypted with a single public key and generating a uniquely decryptable package for each printer identified (e.g., selected) at block <NUM>. Each package may include a PEK encrypted with a public key corresponding to a target printer of the printer group, a policy object encrypted using the PEK, and a content cipher encrypted using a CEK wrapped within the encrypted policy object.

<FIG> depicting method <NUM> includes blocks similar to blocks of <FIG> regarding method <NUM> and provides additional blocks and details. In particular, <FIG> depicts additional blocks and details generally regarding controlling a display, generating a nonce, generating a policy object, and sending ciphers to a print apparatus. Blocks <NUM> and <NUM> are the same as blocks <NUM> and <NUM> of <FIG> and, for brevity, their respective descriptions are not repeated.

At block <NUM>, an input request is caused to present on a display. For example, this may include sending an instruction to a display engine to present information on a display, such as a control panel coupled to a print apparatus. The input request may include a request for input from a user, such as a passphrase to use to secure the print job and/or a selection of a policy rule and/or parameter. At block <NUM>, the KEK is generated from user-associated data including a passphrase received in response to the input request presented at block <NUM>.

At block <NUM>, the CEK is wrapped using the KEK generated from the received passphrase. At block <NUM>, a random nonce is generated. At block <NUM>, a policy object is generated based on a policy selection received in response to the input request at block <NUM>. The policy object generated at block <NUM> is formed to include a wrapped key and the nonce. The policy object may include other information and/or parameters corresponding to a print job and/or a desired release policy. For example, the policy object may include a policy identifier and/or a policy rule, a print parameter, an initialization vector corresponding to a key (such as the CEK), and document information (such as a title, subject, or a creation date). The policy object is encrypted using a PEK at block <NUM>. At block <NUM>, the PEK is encrypted using a public key corresponding to a print apparatus. The policy object may be encrypted using hybrid encryption where the header of the policy object is decryptable using the PEK.

At block <NUM>, print job data (e.g., an electronic document as plaintext) is symmetrically encrypted under the CEK generated at block <NUM> using an authenticated encryption scheme. At block <NUM>, ciphers are sent to a print apparatus. Such ciphers sent to the print apparatus at block <NUM> may include a document cipher (i.e., a cipher corresponding to the print job data encrypted at block <NUM>), a policy cipher (i.e., a cipher corresponding to the policy object encrypted at block <NUM>), and a key cipher (i.e., a cipher corresponding to the PEK encrypted at block <NUM>). The encrypted plaintext document may be sent to the print apparatus along with the encrypted, wrapped CEK. In this manner, the print apparatus may securely receive the information to coordinate printing an electronic document according to a release policy by protecting the key for decrypting the electronic document and policy object are protected by a key encrypted by the public key of the print apparatus. In this manner, the encryption may, for example, prevent man-in-the-middle attacks on the print workflow by binding a document to a specified printer's public key via signed certificates, ensure the chosen printer can learn information about the print job (even if an adversary has knowledge of the user's password), enable detection of alterations to the encrypted job, and allow for printer enforcement of release policies beyond password-based user authentication.

An example encryption workflow <NUM> is depicted in <FIG>. Referring to <FIG>, the work flow begins with the plaintext print job <NUM> (represented as "MW" in <FIG>) and the Rivest-Shamir-Adleman (RSA) public key <NUM> of the target printer (represented as "(N,E)" in <FIG>) being taken as input. An authenticated encryption scheme, such as Chacha20-Poly1305, may be used to encrypt the message using a randomly generated CEK and an initialization vector congruent with the chosen authenticated encryption scheme. For example, an Advanced Encryption Standard (AES), such as AES in Galois/Counter Mode (GCM), may be used. A secure pseudo random number generator may be used to randomly generate a CEK <NUM> and an initialization vector for the content (represented as "CONTENTIV" in <FIG>) is generated according to the security requirements of the authenticated encryption scheme. At block <NUM>, M is encrypted under CEK with the content initialization vector (CIV) using AES-GCM to generate the ciphertext <NUM> (represented as "C" in <FIG>).

The user inputs a password or PIN number (represented as "PW" in <FIG>). At block <NUM>, PW is input to a key derivation function (KDF), such as Password-Based Key Derivation Function <NUM> (PBKDF2), along with a randomly generated salt, to generate a KEK <NUM>. At block <NUM>, the KEK is used to wrap the CEK, via an algorithm that meets the security goals of a key wrap algorithm, such as AES-GCM or misuse resistant mode such as AES in Synthetic Initialization Vector (SIV) mode. The wrapped key <NUM> is represented as "WK" in <FIG>.

A random, <NUM>-bit nonce <NUM> is generated. A subject <NUM> for the print job and other policy requirements <NUM> are input by the user as desired. A policy object <NUM> is created using the above data. The policy object of <FIG> includes the WK, the nonce, the CIV used during the encryption of M, the salt used as input to the PBKDF2, the subject, and the other policy requirements.

A PEK <NUM> and a corresponding initialization vector <NUM> for the policy object (represented as "POLICYiv" in <FIG>) are generated. At block <NUM>, the policy object is encrypted under PEK using AES-GCM with the policy initialization vector (PIV). The resulting ciphertext <NUM> is represented as "Creoucy" in <FIG>.

Known encryption techniques may be used where appropriate with the encryption methods discussed herein. For example, a padding scheme, such as optimal asymmetric encryption padding (OAEP), may be used to process input prior to encryption. At block <NUM>, the PIV, and the PEK are encrypted using RSA-OAEP under the printer's public key (N,E), where N is the printer's RSA modulus and E is the encryption exponent. The resulting ciphertext <NUM> is represented as represented as "CPEK" in <FIG>. The ciphertexts C, CPEK, and CPOLICY are ready to be sent to the printer along with a header that includes the username of the user.

<FIG> are flow diagrams depicting example methods of decryption. The methods <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> of <FIG> are performable by engines, such as a decryption engine <NUM> of <FIG>. Referring to <FIG>, example method <NUM> of decryption may generally comprise recovering a wrapped key, unwrapping the wrapped key using a KEK corresponding to user or policy information, and decrypt an electronic document using the unwrapped key.

At block <NUM>, a policy object having a wrapped key is recovered using a private key corresponding to a print apparatus. At block <NUM>, a KEK is generated using user-associated information or policy-associated information. At block <NUM>, the wrapped key is unwrapped using the KEK generated at block <NUM> to recover a CEK. At block <NUM>, an encrypted electronic document is decrypted using the CEK recovered at block <NUM>.

Referring to <FIG>, a method <NUM> of decryption may include causing operation of components of a print apparatus. At block <NUM>, a control panel is caused to display an input field for a passphrase to be used as user-associated information to generate a KEK (such as at block <NUM> of <FIG>). At block <NUM>, a control panel is caused to display a list of documents available for processing by a print apparatus based on the passphrase. For example, upon entering a passphrase corresponding to a number of documents, the number of documents may be provided in a list to select for printing at the print apparatus.

<FIG> depicts a method <NUM> of decryption using nonce checking. At block <NUM>, a nonce is identified from a package decrypted via PEK. For example, the PEK may be recovered from a decrypting key cipher using a private key corresponding to a print apparatus and the PEK may be used to decrypt a policy object that includes a wrapped key and nonce. At block <NUM>, the nonce identified at block <NUM> is compared to a reference. The reference may be a list of nonces received previously at the print apparatus or a reference nonce (or lists of nonces) provided by a print server.

Whether the nonce is included in the reference is determined at block <NUM> and the determination at block <NUM> governs whether to proceed with the print job or not at block <NUM>. When the nonce of the decrypted policy object is included in the reference, then the print job corresponding to the policy object with the repeated nonce is deleted at block <NUM>. When the decrypted policy object is not included in the reference, the print job corresponding to the package is processed at block <NUM> according to a rule of the policy object. At block <NUM>, the nonce is added to the reference. In this manner, a print job may be prevented from being replayed by an adversary.

Referring to <FIG>, a method <NUM> of decryption may generally comprise obtaining a PEK using a private key, identifying a release policy, generating a KEK, recovering a CEK using the KEK, verifying keys and print job are authentic, printing a decrypted document, and deleting a decrypted data from a print device.

At block <NUM>, a PEK is obtained using a private key corresponding to a print apparatus. At block <NUM>, the PEK obtained at block <NUM> is used to decrypt a policy cipher to obtain a policy object.

At block <NUM>, a rule is identified based on the policy object obtained at block <NUM>. At block <NUM>, a parameter of the print apparatus (such as a printer setting) is set based on a parameter of the policy object obtained at block <NUM>. At block <NUM>, a display is caused to present a request for input upon selection of a print job corresponding to the policy object obtained at block <NUM>.

At block <NUM>, a KEK is generated using policy-associated information and/or user input received from the request displayed at block <NUM>. At block <NUM>, the wrapped key of the policy object is unwrapped using the KEK generated at block <NUM> to recover a CEK. At block <NUM>, the CEK recovered at block <NUM> is verified as valid.

At block <NUM>, an encrypted electronic document is decrypted using the CEK recovered at block <NUM>. The result (e.g., the plain text content) from decrypting the encrypted electronic document is verified as valid or not at block <NUM>. The verified document is printed by the print apparatus at block <NUM>. For example, the print apparatus may perform a print operation of the decrypted electronic document according to a release policy, where the print apparatus operates according to a release policy by setting a parameter of the printer according to a parameter of the policy object and operating a workflow of the printer based on a rule of the policy object. The decryption data is deleted from the print apparatus (e.g., to prevent retrieval from an attacker) at block <NUM>. The decryption data may include the electronic document, the policy object, and any recovered keys. The deletion at block <NUM> may occur after printing is complete or in response to identification that a key, policy, nonce, or document is invalid.

An example decryption workflow <NUM> is depicted in <FIG>. Acronyms used with <FIG> were previously defined with the description of <FIG>. Referring to <FIG>, the printer receives a tuple of ciphertexts including C <NUM>, CPEK <NUM>, and CPOLICY <NUM>. Using the RSA secret key <NUM> (represented as "D" in <FIG>), the printer decrypts CPEK to recover PEK <NUM> and PIV <NUM> at block <NUM>.

At block <NUM>, CPOLICY is decrypted using the recovered PEK to recover the policy object including the wrapped key <NUM>, salt <NUM>, CIV <NUM>, nonce <NUM>, subject <NUM>, and other policy requirements <NUM>. From the information included in the policy object <NUM>, the print apparatus verifies whether the nonce <NUM> is fresh against a list of previously received nonces. If the nonce <NUM> has been presented before, the print job is discarded (i.e., the printer discards C, CPEK, and CPOLlCY). If the nonce <NUM> has not been presented before, the nonce <NUM> is added to the list of previously presented nonces and the workflow continues.

The print apparatus may display text <NUM> corresponding to the subject line of the policy object to the user. The user recognizes the subject and inputs their password/PIN <NUM>, represented as "PW" in <FIG>. At block <NUM>, the user's password/PIN is used as input to the KDF along with the salt <NUM> recovered from the policy object to calculate KEK <NUM>. At block <NUM>, the wrapped key <NUM> is unwrapped via the SIV using KEK <NUM> to recover (and verify the) CEK <NUM>.

At block <NUM>, ciphertext <NUM> is decrypted under the CEK <NUM> (using the CIV recovered in the policy object) to recover (and verify) plaintext document <NUM>. The plaintext document <NUM> is ready to be printed by the print apparatus in accordance with the release policy and all relevant data (e.g., M, PEK, CEK, KEK, WK, C, CPEK, and CPOLICY) is deleted. In this manner, the plaintext document <NUM> may be securely decrypted and prevented from attacks focused on the printer or the user password, for example.

By using the encryption methods and decryption methods discussed herein, man-in-the-middle attacks on the print workflow may be prevented by binding a document to a specified printer's public key via signed certificates, the destination printer may learn information about the print job (even if an adversary has knowledge of the user's password), alterations to the encrypted job may be detectable, and release policies beyond password-based user authentication may be enforced, as examples.

Although the flow diagrams of <FIG> illustrate specific orders of execution, the order of execution may differ from that which is illustrated. For example, the order of execution of the blocks may be scrambled relative to the order shown. Also, the blocks shown in succession may be executed concurrently or with partial concurrence. All such variations are within the scope of the present description.

All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the elements of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or elements are mutually exclusive.

The terms "include," "have," and variations thereof, as used herein, mean the same as the term "comprise" or appropriate variation thereof. Furthermore, the term "based on," as used herein, means "based at least in part on. " Thus, a feature that is described as based on some stimulus may be based only on the stimulus or a combination of stimuli including the stimulus. Furthermore, the use of the words "first," "second," or related terms in the claims are not used to limit the claim elements to an order or location and are merely used to distinguish separate claim elements.

Claim 1:
A method of encryption comprising:
generating a content encryption key to use for encrypting content of an electronic document;
generating a key encryption key from user-associated data or policy-associated data;
wrapping the content encryption key based on a key wrap operation using the key encryption key;
encrypting the wrapped content encryption key using a policy encryption key;
and
encrypting the policy encryption key using a public key corresponding to a print apparatus, further comprising:
generating a policy object including the wrapped content encryption key; and
encrypting the policy object using the policy encryption key to enable a printing apparatus to operate according to a rule of the policy object, such that an electronic document is printed if the rule of the policy object is satisfied.