Tracking of resource utilization during cryptographic transformations

BACKGROUND

00011. Field of the Invention

0002The present invention relates to techniques for exchanging and aggregating information associated with cryptographic transformations.

00032. Related Art

0004The recent proliferation of computer networks and associated advances in networking technology are enabling businesses to improve their services and to offer new services. For example, banks can now provide consumers with the ability to access their bank records and to perform transactions online. However, the ability to exchange such sensitive information over networks creates significant security risks. Indeed, in the wrong hands personal financial information can be used for hacking, identity theft, and other types of criminal activity. To address this problem, systems commonly use encryption to protect data that is transmitted over networks.

0005Unfortunately, cryptographic transformations such as those used in encryption and decryption are computationally intensive. As a consequence, these transformations place significant demands on system resources and are a dominant expense in the processing of data packets. In order to manage systems that perform such cryptographic transformations effectively, it is desirable for the associated resource utilization to be accurately measured. However, the statistics that are measured in existing systems are typically limited to data-packet or byte counts. The actual cost incurred by the system cannot be determined using this information, because the cost also depends on whether or not cryptography was employed, and if so, on what cryptographic technique is used.

0006For example, the processing of network data packets may involve asynchronous-cryptographic operations. These operations often run in a context that is disconnected from the application that consumes the data packets. The ability to effectively manage the associated data flow requires the system to accurately account for resources used or spent by the system to process the data packets. However, in the case of cryptographic asynchronous processing operations these costs are not attributable to the application that generated the data flow. Instead, when executed in software, asynchronous cryptography requests are run in the context of a process (such as a system daemon) that sits idly in the background of the operating system until it is invoked to perform its task, and is then charged for the associated cost. And when offloaded to a hardware cryptographic accelerator, the scheduling cost and time spent in callbacks is diluted in measurement of the overall system overhead.

0007Therefore, in the absence of the ability to accurately monitor cryptographic resource utilization, the increasing use of encrypted data poses challenges to the operators of networks. In particular, it is difficult for the operators to determine cryptographic resource needs, to optimize data processing using the existing resources, to account for expenses, and to provide economic incentives for users to use cryptographic resources efficiently.

0008Hence what is needed is a method and an apparatus that facilitates the tracking of resource utilization during cryptographic transformations without the above-described problems.

SUMMARY

0009One embodiment of the present invention provides a computer system that communicates cryptographic resource utilization information while processing data packets. During operation, the system receives a first data packet and generates a second data packet by performing a cryptographic transformation on the first data packet. Next, the system appends auxiliary information to the second data packet. This auxiliary information includes information associated with cryptographic resource utilization during the cryptographic transformation. Then, the system provides the second data packet including the auxiliary information.

0010In some embodiments, the cryptographic transformation involves decryption and/or encryption of the first data packet, and may be performed, at least in part, in hardware and/or in software. Furthermore, the cryptographic transformation may involve an asynchronous cryptographic process.

0011In some embodiments, the auxiliary information is appended in response to a received command. Furthermore, in some embodiments the auxiliary information specifies a type of cryptographic accelerator, a provider of the cryptographic accelerator, a type of random number generator, a cost of the cryptographic transformation, a number of bytes transformed, and/or processor utilization during the cryptographic transformation. And in some embodiments, the system aggregates auxiliary information associated with multiple data packets.

0012In some embodiments, the first data packet is received and/or the second data packet is provided over a network.

0013In some embodiments, the system determines a user account balance based on the auxiliary information to enable billing based on usage of cryptographic resources. The system may provide the user account balance in response to a user request.

0014In some embodiments, the system determines performance of the system and/or a resource utilization in the system based on the auxiliary information.

0015In some embodiments, the system migrates additional cryptographic transformations of subsequent data packets to additional cryptographic resources based on the auxiliary information. And in some embodiments, the system restricts subsequent access of a user to cryptographic resources based on the auxiliary information.

0016Another embodiment provides a method including at least some of the above-described operations.

0017Another embodiment provides a computer program product for use in conjunction with the computer system.

BRIEF DESCRIPTION OF THE FIGURES

0018<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram illustrating a computer system in accordance with an embodiment of the present invention.

0019<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram illustrating a computer system in accordance with an embodiment of the present invention.

0020<figref idref="DRAWINGS">FIG. 3</figref> is a flow chart illustrating a process for communicating resource utilization in accordance with an embodiment of the present invention.

0021<figref idref="DRAWINGS">FIG. 4</figref> is a block diagram illustrating a data structure in accordance with an embodiment of the present invention.

0022<figref idref="DRAWINGS">FIG. 5</figref> is a block diagram illustrating a data structure in accordance with an embodiment of the present invention.

0023Note that like reference numerals refer to corresponding parts throughout the drawings.

DETAILED DESCRIPTION

0024The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present invention. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

0025Embodiments of a computer system, a method, and a computer program product (i.e., software) for use with the computer system are described. These systems and processes may be used to communicate cryptographic resource utilization when processing data packets. In particular, after encrypting or decrypting an initial data packet that is received, the system may append auxiliary information to a resulting data packet which is then transmitted. This auxiliary information includes information associated with cryptographic resource utilization during the cryptographic transformation. For example, for cryptographic transformations performed, at least in part, in software, the auxiliary information may include a cost of the cryptographic transformation, a number of bytes transformed, and/or processor utilization during the cryptographic transformation. And for cryptographic transformations performed, at least in part, in hardware, the auxiliary information may specify a type of cryptographic accelerator, a provider of the cryptographic accelerator, a number of bytes transformed, a type of random number generator, and/or a cost of the cryptographic transformation. In an illustrative embodiment, the cryptographic transformation includes an asynchronous cryptographic process.

0026The system may use the auxiliary information to determine system performance, to determine a resource-utilization margin in the system, and/or to determine a user account balance to enable billing based on usage of cryptographic resources. Furthermore, by using the auxiliary information the system may migrate additional cryptographic transformations of subsequent data packets to additional cryptographic resources and/or restrict subsequent access of a user to cryptographic resources.

0027The data packets may be received and transmitted over a network, such as the Internet or World Wide Web (WWW), an Intranet, a local area network (LAN) (such as IEEE 802.11 or WiFi), a wide area network (WAN) (such as IEEE 802.16 or WiMAX), a metropolitan area network (MAN), a satellite network, a wireless network (such as a cellular telephone network), an optical network, and/or a combination of networks or other technology enabling communication between computing systems or electronic devices.

0028We now describe embodiments of a computer system, a method, and software for communicating cryptographic resource utilization. <figref idref="DRAWINGS">FIG. 1</figref> provides a block diagram illustrating a computer system <b>100</b> including cryptographic-framework components in accordance with an embodiment of the present invention. In this architecture, data packets <b>110</b> from consumers (i.e., customers using the computer system <b>100</b>) are transmitted and received by a networking sub-system <b>114</b> via link(s) <b>112</b>. The link(s) <b>112</b> may use one or more communication protocols (such as time domain multiplexing, frequency domain multiplexing, and/or code division multiple access) and may include one or more types of links (including wireless and/or wired links, such as coaxial cable or optical fiber). In an exemplary embodiment, the networking sub-system <b>114</b> includes one or more network interface cards (NICs), i.e., circuit boards that include components necessary for sending and receiving the data packets <b>110</b>, which are plugged into available slots in an expansion bus and are coupled to the link(s) <b>112</b>.

0029After demodulating or decoding the format used in the communication protocol(s), the data packets <b>110</b> are processed in a security protocol sub-system <b>116</b> using one or more protocols <b>118</b>. These protocols <b>118</b> may include Internet Protocol Security (IPsec), which is a network or data-packet level protocol that provides confidentiality and authentication in which the integrity of transmitted data is verified. (This protocol is widely used to implement Virtual Private Networks.) In addition, the protocols <b>118</b> may include Kerberos, a secure technique for authenticating a request for a service in a computer system, such as the computer system <b>100</b>.

0030Using program interface <b>120</b>, data packets <b>110</b> from consumers may access one or more cryptographic processes based on an associated service request. In an exemplary embodiment, the program interface <b>120</b> is implemented at the kernel-level in the operating system in the computer system <b>100</b>.

0031Cryptographic core <b>122</b> schedules one or more cryptographic transformations during these cryptographic processes and ensures that the resulting load on the resources in the computer system <b>100</b> is balanced. For example, a given cryptographic transformation may be performed by calling a kernel-level consumer function implemented either using handling code in the operating system, or using an external accelerator. In response, a request may be generate for subsequent scheduling. As discussed below, in some embodiments the best provider of a cryptographic accelerator may be selected prior to scheduling.

0032In some embodiments, the entire kernel of the operating system in the computer system <b>100</b> resides in a protected address space. As a consequence, the cryptographic transformations may be implemented as multiple threads running in parallel on different processors that attempt to simultaneously operate on the same data packet(s). The cryptographic core <b>122</b> may maintain a global queue of asynchronous requests that can be honored only by software (SW) handler (i.e., programs or modules that execute in the environment of the operating system), and may also maintain one queue per registered hardware (HW) accelerator for the requests assigned to it. Furthermore, one kernel thread may be associated with the queue for a corresponding HW cryptographic accelerator.

0033Note that a task of the cryptographic core <b>122</b> is to keep each HW cryptographic accelerator ‘fed’ so as to maximize its usage. In addition, a global software queue in the operating system is serviced by a pool that includes a variable number of kernel threads (which may be created by a user daemon that starts at boot time). This allows the computer system <b>100</b> to limit the allocation of processor resources when processing cryptographic operations in the kernel. Therefore, these threads are created, as needed, as cryptographic demand increases. In this way, use of all of the processors in the computer system <b>100</b> is maximized.

0034In some embodiments, the cryptographic core <b>122</b> may use one or more look-up tables of providers <b>124</b> when performing the scheduling and load balancing functions. In particular, using the look-up table <b>124</b> the cryptographic core <b>122</b> may efficiently determine those cryptographic accelerators capable of handling a request, and then dispatch a call to the most appropriate accelerator or queue a request for later scheduling. For example, each entry in the look-up table <b>124</b> may point to a chain of descriptors for providers of the corresponding cryptographic accelerators. Thus, when handling a request for a Message Digest number 5 (MD5) technique, only accelerators from providers that advertise the ability to handle this mechanism will be considered. Information included in the chain of descriptors may also determine if the identified cryptographic accelerator(s) are also configured to handle a specific request (for example, based on packet-size limitations, data types, etc.)

0035The cryptographic transformations may include hash functions, encryption and/or decryption performed using a given technique. Techniques may include MD5, Secure Hashing Algorithm (SHA-1), Data Encryption Standard (DES), Rivest Cipher 4 (RC4), Rivest Shamir Adleman (RSA), and/or Rijndael Advanced Encryption Standard (AES). Also note that encryption and decryption may be symmetric and/or asymmetric. In the former, encryption and decryption are performed using the same key. In the latter, encryption and decryption are performed using two different keys, one of which is referred to as the public key and the other is referred to as the private key. Asymmetric encryption is also known as public-key encryption.

0036The cryptographic transformations may be performed by one or more of the cryptographic accelerators, including SW cryptographic handlers <b>136</b> and/or HW cryptographic accelerators <b>138</b>. Therefore, in some embodiments the operating system executing in the computer system <b>100</b> may support a pseudo device driver that provides an interface to a public key cryptography standard (PKCS). PKCS is a collection of industry standards for computer security in general that have been fostered by RSA Laboratories. These standards specify programming interfaces used to access services offered by hardware cryptographic devices, such as HW accelerators <b>138</b>. In an exemplary embodiment, the pseudo device driver supports PKCS #11.

0037The SW cryptographic handlers <b>136</b> and/or HW cryptographic accelerators <b>138</b> may be accessed via a provider interface <b>132</b>. Note that these accelerators are different in terms of the capabilities they offer, their limitations, in the way they operate, and in the way they interact with their environment (i.e., the way they interact with the operating system kernel).

0038A SW cryptographic handler (such as SW cryptographic handler <b>136</b>-<b>1</b>) is a loadable kernel module capable of offering cryptographic transformations. SW cryptographic handler <b>136</b>-<b>1</b> may be viewed as a kernel-level library that implements a set of techniques or mechanisms, for example, those defined by PKCS #11. In an exemplary embodiment, SW cryptographic handler <b>136</b>-<b>1</b> is a monolithic module that contains an implementation of one cryptographic technique, but which may include different modes of operation. Typically, the SW cryptographic handlers <b>136</b> operate in a synchronous way, i.e., a call to SW cryptographic handler <b>136</b>-<b>1</b> does not return before completion of the associated cryptographic transformation. In the context of parallel processing or a multi-threaded environment, execution continues on the same thread such that no additional requests are queued to SW cryptographic handler <b>136</b>-<b>1</b>. In contrast with the HW cryptographic <b>138</b> accelerators described below, SW cryptographic handlers <b>136</b> do not maintain a state for their callers.

0039A HW cryptographic accelerator (such as HW cryptographic accelerator <b>138</b>-<b>1</b>) is a device capable of cryptographic transformations. Such a device is accessed by the operating system kernel through a node in the device tree and by using the corresponding device driver. Depending on the price and the intended use, HW cryptographic accelerator <b>138</b>-<b>1</b> may have a single capability (for example, one random-number generator chip) or many techniques or mechanisms (such as a multi-purpose cryptographic accelerator). For most types of cryptographic operations, the HW cryptographic accelerators <b>138</b> operate in an asynchronous mode, i.e., a call to HW cryptographic accelerator <b>138</b>-<b>1</b> is not guaranteed to be completed upon return. Some of the HW cryptographic accelerators <b>138</b> may require a session to be established first and handle requests on a per session basis. However, some of the HW cryptographic accelerators <b>138</b> may operate in a session-less mode, where all the needed information is presented to these accelerators along with the context.

0040Note that in some embodiments the computer system <b>100</b> may allow pending portions of a multi-part cryptographic operation to be canceled before they are completed (for example, using a SA-delete command in IPsec). Thus, in some embodiments SW cryptographic handler <b>136</b>-<b>1</b> may be unloaded and/or HW cryptographic accelerator <b>138</b>-<b>1</b> may be dynamically reconfigured during at least a portion of a group of cryptographic transformations.

0041After the cryptographic transformations are performed, the resulting data packets may be checked by routing the data packets elsewhere in the computer system <b>100</b> using the verifier interface <b>134</b>. In addition, as discussed further below, the cryptographic core <b>122</b> may collect or assemble associated auxiliary information <b>126</b> during the cryptographic transformations that are performed on the data packets <b>110</b>.

0042For a SW cryptographic handler, the auxiliary information <b>126</b> may include the type of cryptographic transformation (encryption, decryption, a Hash-Based Message Authentication Code, digest, sign, and/or verify), a cost of the cryptographic transformation, a number of bytes transformed, and/or processor utilization during the cryptographic transformation (such as a time in nanoseconds spent on the request). And for cryptographic transformations performed, at least in part, using a HW cryptographic accelerator, the auxiliary information <b>126</b> may specify a mechanism or technique used in the cryptographic accelerator, the type of cryptographic transformation (encryption, decryption, a Hash-Based Message Authentication Code, digest, sign, and/or verify), a provider of the cryptographic accelerator, a number of bytes transformed, a type of random number generator, a random number used (if any), and/or a cost of the cryptographic transformation.

0043This auxiliary information <b>126</b> may be appended to corresponding data packets <b>110</b> after processing, i.e., after the cryptographic transformation(s) has occurred. For example, the auxiliary information <b>126</b> may be appended in response to a consumer request. Alternatively, the auxiliary information <b>126</b> may be appended in response to a request from an administrator <b>128</b> or another component in the computer system <b>100</b> (such as the networking sub-system <b>114</b> or one of the protocols <b>118</b> in the security protocol sub-system <b>116</b>). Then, the data packets <b>110</b> and auxiliary information <b>126</b> may be transmitted using the networking sub-system <b>114</b>.

0044As noted above, computer system <b>100</b> may also include administrator <b>128</b> that is configured to regulate the performance (such as resource utilization) and to determine system margin for the entire cryptographic framework. In this regard, the auxiliary information <b>126</b> may allow the administrator <b>128</b> to monitor and control the performance of the computer system <b>100</b>. For example, the administrator <b>128</b> may be able to test performance or diagnose problems. In addition, the administrator <b>128</b> may determine which cryptographic mechanisms or techniques are supported, may determine usage statistics (such as the number of successful and/or failed cryptographic operations), may change or add HW cryptographic accelerators <b>138</b>, and/or may change the number of processors dedicated for SW cryptographic threads, as needed, with minimal disruption.

0045In some embodiments, the administrator <b>128</b> aggregates auxiliary information <b>126</b> associated with multiple data packets. For example, the aggregated auxiliary information <b>126</b> may include that associated with data flows for a virtual NIC, data flows for a given protocol (such as all User Datagram Protocol traffic), and/or data flows for a given service (such as that defined by a transport port). The results may be stored with account information <b>130</b>. The account information <b>130</b> may enable billing of the appropriate consumer associated with a data flow (for example, using an accounting module) based on the consumer's use of system resources. For example, some cryptographic transformations are more expensive than others. These costs may, at least in part, be passed on to the consumer(s). In this way, the consumers may be provided with an incentive to conserve such resources. In addition, the account information <b>130</b> may be provided to corresponding consumers at the request of the consumers. This may allow the consumers to plan their budgets and predict costs.

0046In some embodiments, service providers (such as cellular telephone carriers) may use the auxiliary information <b>126</b> and/or the account information <b>130</b> to bill users based on the type of data they are communicating over a cellular network. In short, this information may enable a new paradigm in which not all data is billed in the same way.

0047Furthermore, the administrator <b>128</b> may use the auxiliary information <b>126</b> to dynamic configure the cryptographic framework. For example, additional cryptographic transformations of subsequent data packets may be migrated to additional cryptographic resources based on the auxiliary information <b>126</b> for a current data packet. In this way, a stream of data packets may be migrated in memory to be closer to the associated cryptographic accelerator(s) or may be offloaded to another sub-system based on resource utilization. And in some embodiments, the system restricts subsequent access of a consumer to cryptographic resources based on the auxiliary information <b>126</b>.

0048Note that in some embodiments the computer system <b>100</b> includes fewer or additional components, two or more components are combined into a single component, and/or a position of one or more components may be changed.

0049In an exemplary embodiment, a HW cryptographic accelerator, such as the HW cryptographic accelerator <b>138</b>-<b>1</b>, is used to perform an RSA cryptographic transformation based on a kernel-level Secure Socket Level (SSL) protocol. During the SSL handshake phase, a client (i.e., a consumer) and the computer system <b>100</b> establish a common secret that both will use later to derive keying materials (keys for encryption and authentication, and initialization vectors). The common secret (also called a pre-master secret) is encrypted before it is communicated to the computer system <b>100</b> such that an eavesdropper cannot figure out its value. During this process, the client generates a random string of bytes and uses a public key provided by the computer system <b>100</b> (for example, in a certificate that was previously sent to the client) to encrypt the pre-master secret with the RSA asymmetric technique. Then, the encrypted pre-master secret is sent to the computer system <b>100</b> in an SSL handshake message called a ClientKeyExchange message. For example, this message may have the format SSL header {msg type=SSL Handshake, version=3.1, length=50, Handshake payload {HandShake type=ClientKeyExchange, Encrypted Pre-master secret (48 bytes)}}.

0050The computer system <b>100</b> receives the CLientKeyExchange message, and submits a request for its decryption in order to recover the pre-master secret. In particular, the networking sub-system <b>114</b> receives the Transmission Control Protocol (TCP) packet carrying the ClientKeyExchange SSL message. This data packet is delivered to the SSL connection or proxy in the security protocol sub-system <b>116</b>. The SSL connection belongs to the SSL flow, and the TCP connection structure points to a flow structure that represents the SSL flow. TCP recognizes a packet coming to the SSL proxy, so it passes it to the proxy code that constructs a request. This request includes a pointer to the encrypted pre-master secret, uses a private key that was previously initialized with the private key of the computer system <b>100</b> (which corresponds to the public key included in the certificate), and requests that auxiliary information <b>126</b> be appended to the results of the cryptographic transformation.

0051The kernel of the cryptographic framework checks for the request for auxiliary information <b>126</b>. If it is set, time readings when the asynchronous request is sent and returned from the hardware RSA accelerator are determined. These time readings are included in the auxiliary information <b>126</b>. In addition, when the RSA hardware accelerator finishes the decryption, it notifies the kernel of the cryptographic framework, which sets the rest of fields in the auxiliary information <b>126</b>. For example, the auxiliary information <b>126</b> also includes that the RSA hardware accelerator has preformed RSA decryption of 48 bytes. Then, the framework notifies the SSL proxy code of the completion of the job and the result of the decryption. In turn, the proxy returns the auxiliary information <b>126</b> to TCP, which updates the flow structure for SSL by charging it the costs (CPU time and provider usage). Observation tools in the administrator <b>128</b> that display the list of flows will report the cumulative time and other resources spent per cryptographic transformation for each flow.

0052In another exemplary embodiment, a SW cryptographic handler, such as the SW cryptographic handler <b>136</b>-<b>1</b>, is used to perform Hash-Based Message Authentication Code (HMAC) for IPsec. A data packet is received by the networking sub-system <b>114</b> over an IPsec tunnel interface that was configured with an IPsec AH (Authentication Header) in tunnel mode, and with SHA-1 as the negotiated authentication technique. The flow structure for that tunnel is pointed to by an interface descriptor structure in the provider interface <b>132</b>.

0053Then, the data packet is submitted for authentication. A cryptographic data set is constructed for the authenticated payload, the authentication key is retrieved from the tunnel's security association structure, and a request is constructed. In this case, no hardware accelerators that support SHA-1 are available on the computer system <b>100</b>. Therefore, the data packet is queued to the software queue of cryptographic asynchronous requests. Later, a thread picks up the request, takes a time reading, and synchronously submits it to the SHA-1 software accelerator.

0054When this accelerator has completed the cryptographic transformation, it returns to the caller (the worker thread), which takes a second time reading and updates the auxiliary information <b>126</b> associated with the request to include the total time spent performing the HMAC verification. Then, the worker thread returns control back to the IPsec code in the security protocol sub-system <b>116</b>. The IPsec code updates the flow structure of the tunnel by charging it the cost of the operation. In this case, observation tools in the administrator <b>128</b> will show the processor time spent performing SHA-1 authentication on behalf of the tunnel's flow.

0055<figref idref="DRAWINGS">FIG. 2</figref> provides a block diagram illustrating a computer system <b>200</b> (such as the computer system <b>100</b>) in accordance with an embodiment of the present invention. The computer system <b>200</b> includes one or more processors <b>210</b>, a communication interface <b>212</b>, a user interface <b>214</b>, and one or more signal lines <b>222</b> coupling these components together. Note that the one or more processing units <b>210</b> may support parallel processing and/or multi-threaded operation, the communication interface <b>212</b> may have a persistent communication connection, and the one or more signal lines <b>222</b> may constitute a communication bus. Moreover, the user interface <b>214</b> may include a display <b>216</b>, a keyboard <b>218</b>, and/or a pointer <b>220</b>, such as a mouse.

0056Memory <b>224</b> in the computer system <b>200</b> may include volatile memory and/or non-volatile memory. More specifically, memory <b>224</b> may include ROM, RAM, EPROM, EEPROM, FLASH, one or more smart cards, one or more magnetic disc storage devices, and/or one or more optical storage devices. Memory <b>224</b> may store an operating system <b>226</b> that includes procedures (or a set of instructions) for handling various basic system services for performing hardware dependent tasks. The memory <b>224</b> may also store procedures (or a set of instructions) in a communication module <b>228</b>. The communication procedures may be used for communicating with one or more computers and/or servers, including computers and/or servers that are remotely located with respect to the computer system <b>200</b>.

0057Memory <b>224</b> may also include multiple program modules (or a set of instructions), including cryptography module <b>230</b> (or a set of instructions), resource-utilization module <b>232</b> (or a set of instructions), optional accounting module <b>234</b> (or a set of instructions), and/or system-performance module <b>236</b> (or a set of instructions). Furthermore, memory <b>224</b> may include one or more random number generators <b>238</b> and/or optional account information <b>252</b>.

0058Cryptography module <b>230</b> may use one or more of accelerators/handlers <b>246</b> in accelerators/handlers <b>244</b> to perform cryptographic transformation on one or more data packets <b>242</b> in data structure <b>240</b>. During these transformations, auxiliary information <b>248</b> for one or more users <b>250</b> may be determined.

0059Instructions in the various modules in the memory <b>224</b> may be implemented in a high-level procedural language, an object-oriented programming language, and/or in an assembly or machine language. The programming language may be compiled or interpreted, i.e, configurable or configured to be executed by the one or more processing units <b>210</b>.

0060Although the computer system <b>200</b> is illustrated as having a number of discrete components, <figref idref="DRAWINGS">FIG. 2</figref> is intended to be a functional description of the various features that may be present in the computer system <b>200</b> rather than as a structural schematic of the embodiments described herein. In practice, and as recognized by those of ordinary skill in the art, the functions of the computer system <b>200</b> may be distributed over a large number of servers or computers, with various groups of the servers or computers performing particular subsets of the functions. In some embodiments, some or all of the functionality of the computer system <b>200</b> may be implemented in one or more ASICs and/or one or more digital signal processors DSPs.

0061The computer system <b>200</b> may include fewer components or additional components, two or more components may be combined into a single component, and/or a position of one or more components may be changed. In some embodiments the functionality of the computer system <b>200</b> may be implemented more in hardware and less in software, or less in hardware and more in software, as is known in the art.

0062We now discuss methods for communicating cryptographic resource utilization. <figref idref="DRAWINGS">FIG. 3</figref> provides a flow chart illustrating a process <b>300</b> for communicating resource utilization in accordance with an embodiment of the present invention. During this process, the system receives a first data packet (<b>310</b>), optionally determines that the first data packet includes instructions requesting auxiliary information (<b>312</b>), and generates a second data packet by performing a cryptographic transformation on the first data packet (<b>314</b>). Then, the system appends auxiliary information to the second data packet (<b>316</b>). This auxiliary information includes information associated with cryptographic utilization during the cryptographic transformation. In some embodiments, the system optionally determines and/or provides a user balance based on the auxiliary information to enable billing based on usage of cryptographic resources (<b>318</b>). And in some embodiments, the system optionally determines system performance and/or resource-utilization margin based on the auxiliary information (<b>320</b>). Note that in some embodiments there may be additional or fewer operations, the order of the operations may be changed, and two or more operations may be combined into a single operation.

0063We now discuss data structures that may be used in the computer system <b>100</b> (<figref idref="DRAWINGS">FIG. 1</figref>) and/or <b>200</b> (<figref idref="DRAWINGS">FIG. 2</figref>). <figref idref="DRAWINGS">FIG. 4</figref> provides a block diagram illustrating a data structure <b>400</b> in accordance with an embodiment of the present invention. This data structure may include auxiliary information <b>410</b>. For example, auxiliary information <b>410</b>-<b>1</b> may include a cryptographic accelerator/handler <b>412</b>-<b>1</b> used, an accelerator provider <b>414</b>-<b>1</b>, a random number generator <b>416</b>-<b>1</b> used, a number of bytes transformed <b>418</b>-<b>1</b>, a cost of the transformation <b>420</b>-<b>1</b>, and/or processor utilization <b>422</b>-<b>1</b>.

0064<figref idref="DRAWINGS">FIG. 5</figref> provides a block diagram illustrating a data structure <b>500</b> in accordance with an embodiment of the present invention. This data structure may include information for user accounts <b>510</b>, such as that in account information <b>130</b> (<figref idref="DRAWINGS">FIG. 1</figref>). For example, for user account <b>510</b>-<b>1</b>, the account information may include cryptographic transformations <b>512</b>-<b>1</b>, charges <b>514</b>-<b>1</b>, and/or optional budget information <b>516</b>-<b>1</b>. Note that that in some embodiments of the data structures <b>400</b> and/or <b>500</b> there may be fewer or additional components, two or more components may be combined into a single component, and/or a position of one or more components may be changed.

0065The foregoing descriptions of embodiments of the present invention have been presented for purposes of illustration and description only. They are not intended to be exhaustive or to limit the present invention to the forms disclosed. Accordingly, many modifications and variations will be apparent to practitioners skilled in the art. Additionally, the above disclosure is not intended to limit the present invention. The scope of the present invention is defined by the appended claims.