Abstract:
This invention provides a system and method for implementing a middleware caching arrangement to minimize device contention, network performance and synchronization issues associated with enterprise security token usage. The invention comprises a token API mapped to a cache API. Logic associated with the token API preferentially retrieves information from a memory cache managed by the cache API. Mechanisms are included to periodically purge the memory cache of unused information.

Description:
[0001]    A portion of the disclosure of this patent document contains material subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.  
         FIELD OF INVENTION  
         [0002]    The present invention relates generally to a data processing system and method and more specifically to remote transaction cache associated with a security token.  
         BACKGROUND  
         [0003]    Security tokens are tamper resistant hardware devices used to securely store digital credentials, cryptographic keys and other proprietary information. The tokens are packaged in a convenient and easily transportable medium and generally communicate with a host client using standardized IEEE serial communications protocols. Examples of security tokens include smart cards, integrated circuit cards, subscriber identification modules (SIM), wireless identification modules (WIM), USB token dongles, identification tokens, secure application modules (SAM), secure multi-media tokens (SMMC) and like devices.  
           [0004]    The single input/output nature of a serial connection is known to cause local device contentions when multiple requests to access the security token are received by the local client. In a multi-user networking environment, serial device contentions can impair network performance as each requesting remote service must wait in line for its request to be processed by a particular security token. The device contentions can be minimized to some extent by assigning priorities to the access requests. However, prioritization does not provide significant performance improvements in operating environments where a multitude of identically prioritized requests occur within a small time frame such as at the start or end of a work day where large numbers of entities are logging into or out of a network.  
           [0005]    A second problem arises when the information contained in the security token is shared among multiple services, Information requested by one application may be altered, moved or deleted by another application resulting in application errors, system crashes and lost data. One solution known in the art is to exclusively lock the security token to a particular application until all transactions between the exclusive application and security token have been completed. This solution has limited usefulness though since exclusively locking the security token for prolonged periods may exacerbate the network performance issues described above.  
           [0006]    Other solutions include the use of secure shared memory arrangements and caching techniques. Memory sharing is useful if the information to be shared does not require extensive security protocols to be implemented. While secure memory sharing mechanisms do exist, the increasing complexity of maintaining the integrity of the shared memory tends to be system resource intensive and inadvertent “security holes” are always a concern. Caching of information is another common technique which provides reasonable performance improvements. An example of a data object caching technique is disclosed in U.S. Pat. No. 6,304,879 to Sobeski, et al. This patent describes a reasonable caching technique suitable for data objects but is not well suited for implementation with a security token as there are no intrinsic security measures incorporated into the disclosed invention.  
           [0007]    Thus, it would be highly advantageous to provide a reasonably secure caching mechanism suitable for implementation with a security token which addresses the limitations described in the relevant art above.  
         SUMMARY  
         [0008]    This invention addresses the limitations described above. The caching mechanism comprises a security token interface applications programming interface (API) which is mapped to a cache API and may be installed in a local client, one or more servers or co-located in both the client and server(s).  
           [0009]    The cache API receives requests for information from the security token interface API which includes a cross reference containing a specific unique identifier associated with the security token and an encoded semantic. The unique identifier is usually a serial number masked into the security token by the token manufacturer. Information is stored in the memory cache by associating the unique security token identifier with the semantic forming a unique cache identifier. It is also envisioned that semantics related to set of security tokens may be cached as well. For example, a semantic may be defined to determine which security tokens contain a digital certificate for updating purposes.  
           [0010]    A separate unique cache identifier is required for each instance of information stored in the memory cache to differentiate data obtained from a single security token. In the preferred embodiment of the invention, handles are used in lieu of the actual serials numbers and/or semantics to simplify the various combinations of unique identifiers and semantics. Handles as defined herein include a pseudonym or token that a program can use to identify and access an object.  
           [0011]    The cache API locates the particular security token record in the memory cache by using a handle related to the security token&#39;s unique identifier, a semantic or both to arrive at the unique cache identifier. If no occurrence of the requested information is included in the cache, the request is redirected to the token interface API for processing and retrieval of the information from a security token.  
           [0012]    If the requested information is not present in the security token, a pseudo-entry is generated by the security token interface API and transferred to the cache API for storage in the memory cache. The pseudo-entry appears to the cache API as regular data entry and is used to prevent future requests for the same missing information being routed to the security token.  
           [0013]    Once information is retrieved from the security token, the security token interface API transfers the information to the cache API for storage in the memory cache where it is available for future retrieval. The type of information to be cached is categorized as non-proprietary, proprietary and administrative. In the preferred embodiment of the invention, the memory cache is divided into three distinct components including a first component generally containing non-proprietary, a second component containing proprietary information, and a third component containing administrative information necessary to manage and utilize the information stored in the other portions of the memory cache. Dividing the memory cache into three separate components provides greater flexibility for future enhancements to the memory cache by simply adding additional cache components.  
           [0014]    The types of information stored in the memory cache include digital certificates, public keys, password information, properties and configurations related to these datum, token management information, security state information and listings of applets installed inside the security token(s). It should be apparent to one skilled in the art that any information retrievable from a security token may be stored in the memory cache.  
           [0015]    An additional feature of this invention includes a residence time limitation for which in formation remains in the memory cache. After a preset period without repeated access, all or the proprietary portion of the memory cache is flushed. To maintain synchronicity with the information retrieved from the security token, a counter mechanism is included to ensure that the calling application receives the latest version of information contained in the security token. 
       
    
    
     BRIEF DESCRIPTION OF DRAWINGS  
       [0016]    The features and advantages of the invention will become apparent from the following detailed description when considered in conjunction with the accompanying drawings. Where possible, the same reference numerals and characters are used to denote like features, elements, components or portions of the invention. It is intended that changes and modifications can be made to the described embodiment without departing from the true scope and spirit of the subject invention as defined in the claims.  
         [0017]    [0017]FIG. 1—is a generalized block diagram illustrating the placement of the invention in various computer systems.  
         [0018]    [0018]FIG. 1A—is a generalized block diagram illustrating the major components included in the invention.  
         [0019]    [0019]FIG. 2—is a detailed block diagram illustrating the routing and data content of a request for information.  
         [0020]    [0020]FIG. 2A—is a detailed block diagram illustrating the initial processing of the request for information by a cache API and associated memory cache components.  
         [0021]    [0021]FIG. 2B—is a detailed block diagram illustrating the retrieval of the requested information from the memory cache.  
         [0022]    [0022]FIG. 2C—is a detailed block diagram illustrating the attempted retrieval of the requested information which is not available from an associated security token.  
         [0023]    [0023]FIG. 2D—is a detailed block diagram illustrating the return of a not available message from the memory cache.  
         [0024]    [0024]FIG. 3—is a detailed block diagram illustrating a request to retrieve information from the memory cache which has not yet been retrieved from the associated security token.  
         [0025]    [0025]FIG. 3A—is a detailed block diagram illustrating a newly retrieved item being stored in the memory cache and generation of associated cross references  
         [0026]    [0026]FIG. 4—is a flowchart illustrating the major steps involved in implementing the preferred embodiment of the invention. 
     
    
     DETAILED DESCRIPTION  
       [0027]    This present invention provides a system and method for caching of information retrieved from a security token to minimize local device contentions, improve network performance and maintain consistency of information stored in an associated security token.  
         [0028]    Referring to FIG. 1, a security token  5  is shown operatively connected to a local client  10 . The local client  10  may be in processing communications over a network  25  with one or more servers  20 ,  20 A. The local client includes one or more applications  30  requiring access to information originally stored in the security token  5 . The application  30  is associated with a token API  35 . The token API  35  is a middleware applications programming interface which communicates with the security token  5  and a local cache API  40 . Requests received from the application  30  usually include a unique identifier associated with a particular security token and a semantic which are converted by the token API  35  into a unique reference identifier for storage in the memory cache  45 .  
         [0029]    The invention may be installed on one or more local clients  10 ,  10 A, one or more servers  20 ,  20 A or both clients and servers  10 ,  10 A,  20 ,  20 A. Each instance of the invention operates independently of each other and may contain the same, overlapping or completely different information. The contents of each cache  45 ,  45 A,  45 B,  45 C is dependent on information requests promulgated by each application  30 ,  30 A,  30 B,  30 C to each token API  35 ,  35 A,  35 B,  35 C and cached by each cache API  40 ,  40 A,  40 B,  40 C.  
         [0030]    For purposes of this invention, if remote caches are implemented rather than local caches, each local client provides the necessary hardware and software interfaces for the security token  5 ,  5 A to communicate with each server  20 ,  20 A but otherwise does not enter into the system.  
         [0031]    [0031]FIG. 1A depicts the details of the invention. The application  30  is associated with a token API  35 . The token API  35  is a middleware applications programming interface which communicates with the security token  5  and a cache API  40 . A counter applet is installed in each security token which increments each time information is written to the security token. The incremented value #  65 A is compared  70  to a reference value #  65 B initially retrieved by the token API  35 . If the incremented value #  65 A does not match the reference value #  65 B, the contents of the memory cache  45  are refreshed before information is released to the requesting application  30 . In an alternative embodiment of the invention, a most recent process identifier (PID) is stored inside the security token which is compared against the PID initially retrieved by the token API to determine if a change has been made to the contents of the security token. Alternative methods such as maintaining and comparing time stamps will work as well.  
         [0032]    The cache API  40  controls the memory cache  45 . The memory cache  45  is divided into at least three components. The first component G  50  of the memory cache  45  retrievably stores generally uncontrolled information for example, public keys, digital certificates and other non-proprietary information. The second component P  55  of the memory cache  45  retrievably stores proprietary information for example, passwords and related information.  
         [0033]    The third component A  60  retrievably stores administrative information used by the cache API  40  to retrieve information stored in the either the general or proprietary cache components  50 ,  55 . The third component A  60  of the memory cache  45  may exist as part of the cache or as a separate lookup table and includes unique reference numbers, cross reference information, and time stamps associated with information stored in the memory cache  45 .  
         [0034]    [0034]FIG. 2 depicts the routing and processing of an incoming request  205 . The application  30  generates or otherwise routes a request for information  205  to the token API  35 . The request  205  includes numeric information concerning the unique token identifier CID[#] and/or a numeric semantic request SEM[#].  
         [0035]    The token API  35  includes logical instructions to first determine if the requested information  205  is available from the cache API  40  and secondly if the information stored in the cache is current  70  before attempting to retrieve the information from the associated security token referenced by CID[#].  
         [0036]    Referring to FIG. 2A, the cache API  40  converts the original request  205  into a unique reference identifier REQ[ 8021 ]  210  which is then routed to the cache API  40  for processing. The cache API  40  performs a lookup function  230  of unique references REQ#  215  contained in the administrative component  60  of the cache using the reference identifier  210 . To better illustrate the lookup function, an example unique reference identifier REQ[ 8021 ]  210  is sent to the administrative component A  60  to determine if the requested information  210  has already been retrieved.  
         [0037]    In this example, a match is found  230  indicating that the requested information  210  is already present in the memory cache  45 . The unique cache identifiers C#  245  are used to both uniquely identify the requested information and also determine which cache component contains the information. In this example, cache identifiers beginning with the number 2 denotes proprietary information which is stored in the second cache component P  55 . Cache identifiers beginning with a 1 are stored in the first cache component G  50  under cache identifier C#  235 .  
         [0038]    A new time stamp  232  is applied to the identified information  230 . The time stamps  225  are used to define the residence time for information stored in the memory cache  45  and are adjustable to suit different operating conditions. If after a predetermined period has expired without repeat access to a particular piece of stored information, the unused information is flushed from the cache.  
         [0039]    [0039]FIG. 2B continues with the example described above, in which the unique cache identifier  202   264  points  234  to the second cache component P  55  which allows retrieval  269  of the information PW 2   268  associated with unique cache identifier  202   266 . The retrieved information  255  is then returned  275  to the calling application  30  via the token API  35 .  
         [0040]    Referring to FIG. 2C, a problem could arise where a request for non-existent information causes repeat attempts to access the security token, defeating the purpose of the cache. To prevent this situation, after the first occurrence of the unavailable information, the cache API  40  generates a pseudo entry which is stored in the appropriate cache component  50 ,  55  by the cache API  40 . Upon receipt of an otherwise valid request REQ[ 8017 ]  260 , the cache API  40  performs a lookup  257  which points  270  to a pseudo entry  271  contained  272  in the first cache component G  50  and updates the time stamp  265  associated with this entry.  
         [0041]    [0041]FIG. 2D continues with the example described in above, in which a ‘not available’ NA  273  message is retrieved  275  by the cache API  40  and forwarded INFO[NA]  280  to the requesting application.  
         [0042]    Referring to FIG. 3, this last example depicts the case where a request for information has not previously been processed. An incoming request  305  REQ[ 8055 ] is processed by the cache API  40  and no match is found  310 . A not found message NF  315  is generated by the cache API and sent  320  to the token API  35  which signals the token API  35  to retrieve the information from the security token originally identified in the received request.  
         [0043]    In FIG. 3A, the information is retrieved by the token API  35  and sent  327  to the cache API  40  for storage. A new entry  347  is added to the administrative cache component  330 , a new cache ID  203   349  and a new time stamp  345  are assigned to the entry. The new information PW 3   353  is stored  340  in the proprietary cache component 3according to the newly generated cache identifier  203   351 .  
         [0044]    In FIG. 4, the steps to implement the preferred embodiment of the invention are depicted. The process is initiated  400  by a request for information being received  405  by the token API. The token API then determines if the information contained in the memory cache is current  410 . If the information of the cache is current  410  the request is routed directly to the cache API for processing  420 . If the information is not current  410 , the cache is first refreshed  415  then referred to the cache API  420  for processing.  
         [0045]    The cache API determines if the requested information is available from the cache  425 . If the information is not available from the cache  425  the cache API notifies the token API to retrieve the information from the associated security token  430 . If the information is not available from the security token  440 , the token API generates a pseudo cache entry  445  which is stored in the memory cache by the cache API, a not available “A” message is returned to the requester  460 , a new time stamp entry is created  465  by the cache API, followed by processing termination  470 .  
         [0046]    If the information is available from the security token  450 , the information is retrieved, a copy stored in the memory cache  450 , the information returned to the requestor  455 , a new time stamp entry is created  465  for the new entry by the cache API, followed by processing termination  470 .  
         [0047]    If the information is directly available from the cache  425 , the cache API retrieves the information from the cache  435 , the information returned to the requestor  455 , the time stamp entry is updated  465  by the cache API, followed by processing termination  470 .  
         [0048]    The foregoing described embodiments of the invention are provided as illustrations and descriptions. They are not intended to limit the invention to precise form described. In particular, it is contemplated that functional implementation of the invention described herein may be implemented equivalently in hardware, software, firmware, and/or other available functional components or building blocks. No specific limitation is intended to a particular security token operating environment. Other variations and embodiments are possible in light of above teachings, and it is not intended that this Detailed Description limit the scope of invention, but rather by the claims following herein.