Abstract:
An embodiment generally relates to a method of accessing a secure computer. The method includes capturing an authentication state of a security token in response to a verification of user authentication information. The method also includes providing the authentication state to at least one application requiring authentication with the security token and accessing the at least one application.

Description:
FIELD 
       [0001]    This invention generally relates to secure client-server systems. More particularly, the invention relates to a method and system secure shared smartcard access to a secure client. 
       DESCRIPTION OF THE RELATED ART 
       [0002]    Computer security is a field of computer science concerned with the control of risks related to use of computer systems. In computer security, authentication is a process of determining whether a computer, a software application, or a user is, in fact, what or who it is declared to be. 
         [0003]    An example of user authentication is a user credential, such as a user name and password. Requirements for user credentials may be different among multiple software applications, which complicate a user&#39;s access to multiple software applications during the same work session. For example, healthcare workers may use healthcare-related applications, such as clinical results reporting, physician order entry, and chart completion, and may use general-purpose software applications, such as e-mail, time and attendance, accounting, human resources self-service, and incident reporting. 
         [0004]    Single sign-on (SSO) is a specialized form of software authentication that enables a computer, a computer program, or a user to authenticate once, and gain access to multiple software applications and/or multiple computer systems. For example, in a client/server environment, SSO is a session/user authentication process that permits a user to present one set of credentials at one time in order to access multiple software applications. The SSO credentials, which is requested at the initiation of the session, authenticates the user to access the software applications on the server that have been given access rights, and eliminates future authentication prompts when the user switches between software applications during a particular session. Examples of SSO or reduced signon systems include: enterprise single sign-on (E-SSO), web single sign-on (Web-SSO), Kerberos, and others. 
         [0005]    E-SSO, also called legacy single sign-on, after primary user authentication, intercepts log-on prompts presented by secondary applications, and automatically fills in fields such as a log-on ID or password. E-SSO systems allow for interoperability with software applications that are unable to externalize user authentication, essentially through “screen scraping.” However, E-SSO requires cooperation among computers in the enterprise, and is sometimes referred to as enterprise reduced sign-on. 
         [0006]    Although E-SSO is a solution in enterprises that have a single type of authentication scheme, primarily the ID/password. However, secure enterprise systems typically have multiple log-in systems such as a trusted patch authenticated smart card or a biometric based log-in system. The E-SSO solution cannot operate in these multiple log-in systems because the E-SSO solution has no direct access to the authentication information. 
         [0007]    In some instances, a user may log-on to a secure machine with a smart card in the secure multi-user environment. A problem may arise if a second user logs into the secure machine with the first user&#39;s smart card inserted. One goal would be to prevent the second user from pretending to be the first user and causing havoc. However, this has to be balanced with the burden of requiring a user to enter a personal identification number to access each application in a session. The issue then becomes how to authenticate to a smart card once as a user and allow other people to use the smart card for other operations. More generally, how to share a log-in state with trusted applications. 
       SUMMARY 
       [0008]    An embodiment generally relates to a method of accessing a secure computer. The method includes capturing an authentication state of a security token in response to a verification of user authentication information. The method also includes using the authentication state to provide authenticated services for the at least one application requiring authentication with the security token and accessing the at least one application. 
         [0009]    Another embodiment generally pertains to a system for secure access. The system includes a computing machine configured to access a multi-user multi-machine system and a security device interface with the computing machine. The security device is configured to accept a security token for accessing the computing machine. The system also includes a security daemon configured to be executing on the computing machine. The security daemon is configured to initiate a session and capture an authentication state of a security token in response to a verification of user inputted authentication information. The security daemon may also bind the authentication state to the session. 
     
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0010]    Various features of the embodiments can be more fully appreciated as the same become better understood with reference to the following detailed description of the embodiments when considered in connection with the accompanying figures, in which: 
           [0011]      FIG. 1  illustrates an exemplary system  100  in accordance with an embodiment; 
           [0012]      FIG. 2  illustrates an architectural diagram of the computing machine in accordance with another embodiment; 
           [0013]      FIG. 3  illustrates an exemplary flow diagram in accordance with yet another embodiment; 
           [0014]      FIG. 4  illustrates another exemplary flow diagram executed by the computing machine in accordance with yet another embodiment; 
           [0015]      FIG. 5  illustrates yet another exemplary flow diagram in accordance with another embodiment; 
           [0016]      FIG. 6  illustrates an exemplary computing machine. 
       
    
    
     DETAILED DESCRIPTION OF EMBODIMENTS 
       [0017]    For simplicity and illustrative purposes, the principles of the present invention are described by referring mainly to exemplary embodiments thereof. However, one of ordinary skill in the art would readily recognize that the same principles are equally applicable to, and can be implemented in, all types of secure distributed environments and that any such variations do not depart from the true spirit and scope of the present invention. Moreover, in the following detailed description, references are made to the accompanying figures, which illustrate specific embodiments. Electrical, mechanical, logical and structural changes may be made to the embodiments without departing from the spirit and scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense and the scope of the present invention is defined by the appended claims and their equivalents. 
         [0018]    Embodiments pertain generally to a method of sharing a security token among applications within a session. More particularly, a user may insert a security token, such as a smart card, into a secure computing machine and begin logging into the secure machine. An application may detect the presence of the inserted smart card and prompt the user to begin the log-on process. The user may authenticate to the security daemon, which then authenticate to the security token with the user entered authentication information. The security daemon may be configured to capture the authentication state and represent the authenticated security token to other applications in the session. In other words, the security daemon would log into the token, keep the token logged in and then use the fact that it has the token opened and logged in to perform operations on behalf of the user. As a result, the security daemon appears to the rest of the processes in the session that the security token is inserted through a Public Key Cryptography Standard (PKCS) #11 interface. Applications that require authentication may query the security daemon for authentication using the same PKCS #11 calls as they do in conventional smart card systems. Moreover, the security daemon may “own” the representation of the security token being inserted, i.e., the authentication state, by locking access to the card. As a result, other processes and/or applications cannot co-opt the authentication state in tokens that do not hold separate authentication states for different processes such as those defined in the PIV standards. 
         [0019]    Other embodiments relate to accessing remote computers. More specifically, the security daemon provides a mechanism for secure shell (ssh) access to remote computing machines. More particularly, a local machine may securely connect to the remote machine using ssh protocols. The ssh application may advertise a PKCS #11 port that receives PKCS #11 calls on the remote client. During the authentication process, the remote computer may pass queries for authentication through the advertised port over the secured connection between the local and remote machines. The queries are directed to the security daemon, which presents the authentication state to the remote machine. After authentication, a user has access to the resources on the remote computer as though the user was physically logged-on in at the remote computer. 
         [0020]      FIG. 1  illustrates an exemplary secure system  100  in accordance with an embodiment. It should be readily apparent to those of ordinary skill in the art that the system  100  depicted in  FIG. 1  represents a generalized schematic illustration and that other components may be added or existing components may be removed or modified. Moreover, the system  100  may be implemented using software components, hardware components, or combinations thereof. 
         [0021]    As shown in  FIG. 1 , the secure system  100  includes a server  105 , clients  110  and a local network  115 . The server  105  may be a computing machine or platform configured to execute secure and unsecure (or open) applications through a multiple user operating system (not shown) in conjunction with the clients  110 . The server  105  may be implemented with server platforms as known to those skilled in the art from Intel, Advanced Micro Devices, Hewlett-Packard, etc. 
         [0022]    The server  105  may interact with the clients over the local network  115 . The local network  115  may be a local area network implementing an established network protocol such as Ethernet, token ring, FDDI, etc. The local network  115  provides a communication channel for the server  105  and clients  110  to exchange data and commands. 
         [0023]    The clients  110  may be computing machine or platform (machine) configured to execute secure and open applications through the multi-user operating system. The clients  110  may be implemented with personal computers, workstations, thin clients, thick clients, or other similar computing platform. 
         [0024]    Each client  110  may be configured to interface with a security device  120 . The security device  120  may be configured to act as a gatekeeper to the client  110 . More particularly, a user may use a security token, such as a smart card, to access the respective client  110 . Each client  110  may have a security daemon  125  executing to monitor the security device  120 , which is illustrated in  FIG. 2 . 
         [0025]    As shown in  FIG. 2 , a client  110  may be executing a multi-user operating system (OS)  205 . The OS may be Linux, HPUX, or other similar operating systems. The security daemon  125  executes within the OS  205 . The OS  205  may also interface with the secured applications  210  as well as unsecured applications (not shown). Secure application  210  may any type of software that requires authentication from the smart card to initialize and execute. 
         [0026]    The OS  205  may also interface with an application program interface (labeled as API in  FIG. 2 )  215 . The API  215  provides an interface between devices and the OS  205  transmitting and receiving data and commands therebetween.  FIG. 2  shows the security device  120  and a network interface  220  interfaced with the API  215 . The network interface  220  may also be configured to interface with local network  115 . A client may use the network interface  220  to initiate secure shell (SSH) protocols to form a secure connection with remote computers from the client  110 . SSH applications are well-known to those skilled in the art. 
         [0027]    Returning to  FIG. 1 , the security daemon  125  may be configured to detect the presence of the inserted security token and prompt the user to begin the log-on process. The user may authenticate to the security daemon  125 , which then authenticates to the security token with the user entered authentication information. The security daemon  125  may be configured to capture the authentication state and represent the authenticated security token to other applications in the session. The security daemon  125  may also be configured to interface with other processes and/or applications in the session with a PKCS #11 interface. PKCS #11 is a cryptographic token interface standard known to those skilled in the art. 
         [0028]    The secure system  100  may also comprise a second network  130  that may be interfaced with local network  115 . A remote client  110 ′ may be connected with the second network  130 . The remote client  110 ′ may be similar to client  110  with a security device  120 ′. The security device  120 ′ may also function as a gatekeeper to the remote client  110 ′. Accordingly, a user may remote login to the remote client  110 ′ from one of the client  110  using secure shell (ssh) protocols. SSH protocols are well-known to those skilled in the art. During the remote log-in, the client  110  may create a secure connection using ssh protocols to connect with the remote client  110 ′. The ssh application may be configured to publish the PKCS #11 port of the client computer  110  to the remote client  110 ′. The remote client  110 ′ may forward authentication queries through the PKCS #11 port over the secure connection to the client  110 . The security daemon  125  on the client  110  presents its authentication state to answer the authentication queries of the remote client  110 ′. Since the user of client  110  is a valid user, the remote client  110 ′ may grant access to the client  110  as though the user was logged on at the remote client  110 ′. This process may also be used to remote access client  110  from another client  110 . 
         [0029]      FIG. 3  illustrate a flow diagram  300  executed by the security daemon  125  in accordance with another embodiment. It should be readily apparent to those of ordinary skill in the art that the flow diagram  300  depicted in  FIG. 3  represents a generalized illustration and that other steps may be added or existing steps may be removed or modified. 
         [0030]    As shown in  FIG. 3 , the security daemon  125  may be configured to be in an idle state, in step  305 . More particularly, the security daemon  125  may have been instantiation as part of the normal boot sequence. In some embodiments, the security daemon  125  may be instantiated by a system administrator or in response to an event such as the insertion of a security token in the security device  120 . 
         [0031]    In step  310 , the security daemon  125  may be configured to detect the presence of the security token (i.e., a smart card, PIV smart card, etc.) in the security device  120 . The security daemon  125  may then be configured to prompt the user to begin log-on, in step  310 . More particularly, the security daemon  125  may prompt the user for authentication information such as personal identification number (PIN), a password or biometric parameter (retinal scan, fingerprint, etc) or enter the same into some trusted patch device. The security daemon  125  may display a dialog box to requesting the user for the authentication information. 
         [0032]    In step  320 , the security daemon  125  may be configured to pass the user authentication information to the security token for verification or to request that the token read the authentication information from it&#39;s trusted path. If the security token fails to verify, the authentication information, in step  325 , the security daemon  125  may be configured to inform the user of the verification failure. In some embodiments, the security daemon  125  may prompt the user to re-enter the authentication information in step  315 . Alternatively, the security daemon  125  may inform the user that verification failed and return to the idle state of step  305 . Alternatively, the security token may detect too many failed attempts to authenticate and the security daemon  125  may be configured to inform the user that the security token is locked. 
         [0033]    Otherwise, if the authentication information is verified, in step  325 , the security daemon  125  may be configured to capture and hold the authentication state of the inserted security token, in step  335 . More specifically, this may be done by holding a PKCS #11 session open and attaching the security token with which the security daemon  125  could perform additional requests against the security token. The security daemon  125  may then represent itself as the authenticated security token to other applications through a PKCS #11 interface. In other words, the security daemon  125  appears to the rest of the processes in the session that the security token is inserted. 
         [0034]    In step  340 , the security daemon  125  may be configured to bind the authentication state with the current session state of the user. More particularly, in the situation where an application requests requests an initial authentication of the smart card. The application may initially authenticate to the security daemon  125  with some user session mechanism (usually something initialized at login) that does not involve user action (i.e., application authentication). The security daemon  125  would present that authentication information on behalf of the user for that application. Typical implementations of application authentication would include passing magic cookies, environment variables, file descriptors, shared memory segments, etc. to child processes of the parent session, using OS access controls, etc. If an application is part of the session, the security daemon  125  may be configured to implement the steps of  FIG. 3  or could choose to only allow a single user session to be logged in. 
         [0035]      FIG. 4  depicts a flow diagram  400  executed by secure applications  210  in accordance with yet another embodiment. It should be readily obvious to one of ordinary skill in the art that existing steps may be modified and/or deleted and other steps added in  FIG. 4 . 
         [0036]    As shown in  FIG. 4 , a user may initiate a secure application  210 , in step  405 . More specifically, once the user has logged into a session, the user may click on an icon that represents the secure application  210 . Alternatively, a command line prompt or menu selection may be used to invoke the secure application  210 . 
         [0037]    In step  410 , as part of the instantiation of the secure application  210 , the secure application  210  may be configured to query the security device  120  to determine whether the user has privileges to execute the secure application  210 . Typically, secure applications  210  execute a call to the PKCS #11 interface. For these embodiments, the PKCS #11 interface may be connected to the security daemon  125 . 
         [0038]    In step  415 , the secured application  210  call to the PKCS #11 interface may be answered by the security daemon  125 , which holds the authentication state of the security token. The PKCS #11 interface returns a message that the security token is inserted and begins verification between the secure application  210  and the security daemon  125 . 
         [0039]    If verification fails, in step  420 , the secure application  210  may display a dialog message informing that access to the secure application is denied, in step  425 . Otherwise, if verification is successful, in step  420 , the secure application  215  continues to instantiate and the user is granted access, in step  430 . 
         [0040]      FIG. 5  depicts a flow diagram  500  implemented by a client  10  accessing a remote client in accordance with yet another embodiment. It should be readily obvious to one of ordinary skill in the art that existing steps may be modified and/or deleted and other steps added in  FIG. 5 . 
         [0041]    As shown in  FIG. 5 , a user may initiate a secure shell (ssh) application on a client  110  to access a remote client, in step  505 . More specifically, once the user has logged into a session, the user may click on an icon that represents the ssh application. Alternatively, a command line prompt or menu selection may be used to invoke the ssh application. 
         [0042]    In step  510 , the ssh application may be configured to form a secure connection from the client  110  to the remote client. Once connected to the remote computer, the two clients may begin authentication. 
         [0043]    In step  515 , the client  110  may receive authentication queries from the remote client over the secure connection. More specifically, the remote client may execute a call to the PKCS #11 interface which is forwarded to the PKCS #11 interface of the security daemon  125  on the client  110 . 
         [0044]    In step  520 , the forwarded call to the PKCS #11 interface may be answered by the security daemon  125 , which holds the authentication state of the security token. The PKCS #11 interface returns a message that the security token is inserted to the remote client and begins verification between the remote client and the security daemon  125 . 
         [0045]    If verification fails, in step  525 , the remote client may display a dialog message informing that access is denied, in step  530 . Otherwise, if verification is successful, in step  525 , the remote client may grant access to the client computer, in step  535 . 
         [0046]      FIG. 6  illustrates an exemplary block diagram of a computing platform  600  where an embodiment may be practiced. The functions of the security daemon may be implemented in program code and executed by the computing platform  600 . The security daemon may be implemented in computer languages such as PASCAL, C, C++, JAVA, etc. 
         [0047]    As shown in  FIG. 6 , the computer system  600  includes one or more processors, such as processor  602  that provide an execution platform for embodiments of the security daemon. Commands and data from the processor  602  are communicated over a communication bus  604 . The computer system  600  also includes a main memory  606 , such as a Random Access Memory (RAM), where the security daemon may be executed during runtime, and a secondary memory  608 . The secondary memory  608  includes, for example, a hard disk drive  610  and/or a removable storage drive  612 , representing a floppy diskette drive, a magnetic tape drive, a compact disk drive, etc., where a copy of a computer program embodiment for the security daemon may be stored. The removable storage drive  612  reads from and/or writes to a removable storage unit  614  in a well-known manner. A user interfaces with the security daemon with a keyboard  616 , a mouse  618 , and a display  620 . The display adapter  622  interfaces with the communication bus  604  and the display  620  and receives display data from the processor  602  and converts the display data into display commands for the display  620 . 
         [0048]    Certain embodiments may be performed as a computer program. The computer program may exist in a variety of forms both active and inactive. For example, the computer program can exist as software program(s) comprised of program instructions in source code, object code, executable code or other formats; firmware program(s); or hardware description language (HDL) files. Any of the above can be embodied on a computer readable medium, which include storage devices and signals, in compressed or uncompressed form. Exemplary computer readable storage devices include conventional computer system RAM (random access memory), ROM (read-only memory), EPROM (erasable, programmable ROM), EEPROM (electrically erasable, programmable ROM), and magnetic or optical disks or tapes. Exemplary computer readable signals, whether modulated using a carrier or not, are signals that a computer system hosting or running the present invention can be configured to access, including signals downloaded through the Internet or other networks. Concrete examples of the foregoing include distribution of executable software program(s) of the computer program on a CD-ROM or via Internet download. In a sense, the Internet itself, as an abstract entity, is a computer readable medium. The same is true of computer networks in general. 
         [0049]    While the invention has been described with reference to the exemplary embodiments thereof, those skilled in the art will be able to make various modifications to the described embodiments without departing from the true spirit and scope. The terms and descriptions used herein are set forth by way of illustration only and are not meant as limitations. In particular, although the method has been described by examples, the steps of the method may be performed in a different order than illustrated or simultaneously. Those skilled in the art will recognize that these and other variations are possible within the spirit and scope as defined in the following claims and their equivalents.