Patent Publication Number: US-10762245-B2

Title: Input peripheral device security

Description:
BACKGROUND 
     Automated Teller Machines (ATM) are in general believed to be relatively secure devices since they handle consumer financial transactions. However, ATMs are susceptible to malware, viruses, and eavesdropping just like any other device having memory and processor capabilities. 
     Modern ATMs often include peripheral ports or wireless technologies (such as WiFi, Bluetooth®, etc.) which may permit peripheral or device pairing with the ATMs. Generally, the wireless technologies are secured through encryption keys. The peripheral ports may be hidden out of typical sight but service engineers know here the ports are at and how to access them and some ingenious hackers may know how to gain access to the ports. 
     One particular peripheral that may be beneficial to connect to an ATM for legitimate reasons and/or malicious reasons is a keyboard. With a keyboard a service engineer can use keys or key sequences to access resources or run programs on the ATM, which may be unavailable via a typical touchscreen of existing limited encrypted PINPAD. 
     However, because keys and key sequences can bypass some security checks and directly access resources that can be detrimental to the security of the ATM. Some ATM security systems will block all users from certain keys or key sequences through the operating system&#39;s (OS&#39;s) registry. However, this approach is too rigid since an authorized user of the ATM may have a legitimate need to access the blocked keys or key sequences). 
     Therefore there is a need for improved finer-grain security associated with keys and key sequences of peripheral keyboards attached to a host machine. 
     SUMMARY 
     In various embodiments, methods and a Self-Service Terminal for input peripheral device security are presented. 
     According to an embodiment, a method for input peripheral device security is presented. Specifically, an input command generated from an input peripheral of a host machine is intercepted. Then, a determination is made as to whether to block the input command from being processed by an Operating System (OS) of the host machine or whether to pass the input command to the OS for processing. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a diagram of a banking system for keyboard security on an Automated Teller Machine (ATM), according to an example embodiment. 
         FIG. 2  is a diagram of a method for input peripheral device security, according to an example embodiment. 
         FIG. 3  is a diagram of another method for input peripheral device security, according to an example embodiment. 
         FIG. 4  is a diagram of a Self-Service Terminal (SST), according to an example embodiment. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  is a diagram of a banking system for keyboard security on an Automated Teller Machine (ATM), according to an example embodiment. It is to be noted that the components are shown schematically in greatly simplified form, with only those components relevant to understanding of the embodiments being illustrated. 
     Furthermore, the various components (that are identified in the  FIG. 1 ) are illustrated and the arrangement of the components is presented for purposes of illustration only. It is to be noted that other arrangements with more or less components are possible without departing from the teachings of input peripheral device security, presented herein and below. 
     The banking system  100  includes a bank branch  110 , an ATM host/switch  130 , and a core banking system  140 . The bank branch  110  includes: an ATM  111  and a branch server  120 . 
     The ATM  111  includes one or more Central Processing Units (CPU(s)  112 , memory  113 , and a Hard Drive (HD)  115  (which may or may not be encrypted and dynamically decrypted as needed), and multiple peripheral devices  116 . The memory  113  includes new and novel custom peripheral filter agent  114 A as a running instance of executable instructions processed from the memory  113  by the one or more CPUs  112  on the ATM  111 . The HD  115  includes drivers/application code/etc.  115 A, an operating system (OS)  115 B, and files  115 C. The application code  115 A may include the source code for the custom peripheral agent  114 . 
     On ATM  111  boot, the OS  115 B is loaded from the HD  115  into the memory  113  and executed by the one or more CPUs  112 , the OS  115 B when loaded to memory  113  loads the executable version of the custom peripheral filter agent  114 A into memory  113  along with the peripheral drivers  115 A. The custom peripheral filter agent  114 B loads from the files  115 C a novel whitelist  114 B into memory (cache). 
     The custom peripheral filter agent  114 B can communicated over a network connection from the ATM  111  to the branch server (such as through a Local Area Network (LAN) connection. Through the branch server  120  a Wide Area Network (WAN) connection is available to the custom peripheral filter agent  114 A for two-way communication with the custom peripheral filter manager  141  of the core banking system  140 . 
     The custom peripheral filter manager  141  may also change information present in the whitelist  114 B through communication with the custom peripheral filter agent or by replacement of the a file representing the whitelist  114 B in the files  115 C of the hard drive when the customer peripheral filter agent  114 A is not loaded and running in memory  112  of the ATM  111 . 
     During operation, the custom peripheral filter agent  114 A is configured to detect key events and key sequences from a detected keyboard peripheral  116  interfaced to the ATM  111 . This can be done through listening to the port to which the keyboard peripheral  116  is interfaced to the ATM  111  (such as through a Universal Serial Bus (USB port) or other port including a wireless communication port) and/or monitoring commands being sent to and from a device driver associated with the keyboard peripheral  116 . 
     Any key events (can include key sequences) or key commands detected are intercepted from the device driver before being handled by the OS  115 B and compared by the custom peripheral filter agent  114 A to entries in the whitelist  114 B. If a match for an entry in the whitelist  114 B is found, then the key event or key command is allowed to pass to the OS  115 B for normal handling on the ATM  111 . However, if no match is found for an entry in the whitelist  114 B with the intercepted key event or key command, the key event or key command is not passed to the OS  115 B for handling; essentially the intercepted key even or key command is filtered, ignored and results in no action whatsoever on the ATM  111 . 
     Because processing actions of the custom peripheral filter agent  114 A is driven from the whitelist  114 B when new keyboards are deployed only known and certified keys or key sequences can be added in the whitelist  114 B and the custom peripheral filter agent  114 A does not need modified, recompiled, or changed in any way. In this sense, the custom peripheral filter agent  114 A is dynamically customizable and reactive. Moreover, unlike other approaches that rely on identifying keys or key sequences that are to be excluded by utilizing a novel whitelist approach, any unknown and uncertified keys or keys sequences are by default filtered and ignored by the custom peripheral filter agent  114 A because only acceptable keys or key sequences are present and allowed to proceed if present in the whitelist  114 B. 
     Moreover, since the custom peripheral filter manager  141  has access to change the whitelist  114 B new keys or key sequences can be dynamically and remotely added or existing keys or key sequences present in the whitelist  114 B can be dynamically deleted and thereby filtered and ignored because their presence is removed from the whitelist  114 B. 
     A variety of security conditions with respect to the detected key events can be defined in either the whitelist  114 B or a separate configuration file obtained from the files  115 C and dynamically interpreted by the custom peripheral filter agent  114 A. These conditions may be referenced in collections as a specific policy and each policy may be located based on an identity of a resource that triggers the key event or key sequences. For example, a service engineer authenticates via a login procedure and is represented as a unique identity associated with that service engineer. When the key event is intercepted by the custom peripheral filter agent  114 A, metadata available from the OS  115 B can identify the authenticated service engineer&#39;s identity, which the custom peripheral filter agent  114 A locates in a configuration file or the whitelist associated with a condition or a set of conditions referenced as a policy. Those conditions can be evaluated to determine that even if a key event match is found in the whitelist  114 B, the key event is to be ignored or filtered and not passed to the OS  115 B for handling. 
     In this manner, the custom peripheral filter agent  114 A can deploy fine grain and resource specific key command filtering, which can be dynamically changed through changes to entries in the whitelist  114 B and/or the configuration file and which can be changed over a network by the custom peripheral filter manager  141 . 
     This provides a variety of beneficial usages such as but not limited to: 
     1) changes to the filtered keys can come from the remote network-based custom peripheral filter manager  141 ; 
     2) changes to be made to which keys in the whitelist  114 B can be permitted based on a server engineer&#39;s authorization (identity which may be based on a secure USB dongle have a serial number known to be assigned to a specific service engineer); 
     3) keyboard filter changes can be dynamically made without requiring any registry entries in the OS and without requiring the ATM  111  to reboot; and 
     4) keyboard filtering can be remotely managed from the custom peripheral filter manager  141  and/or through configuration conditions or policies, such that filtering can be turned off during an engineer service ticket window and turned back on when the time is outside the service ticket window; 
     In an embodiment, the conditions are based on an automated software resource rather than a user resource (service engineer). 
     In an embodiment, the conditions are integrated into the whitelist  114 B as one file or a database. 
     In an embodiment, the keyboard peripheral  116  is a Bluetooth® keyboard. 
     In an embodiment, the keyboard peripheral  116  is a device operated by the service engineer than can pose as a keyboard for the ATM  111 , such as a laptop, a tablet, a phone, or a wearable processing device configured to identify itself over a peripheral communication port to the ATM  111  as a type of keyboard peripheral  116 . 
     In an embodiment, the whitelist groups whitelisted key entries based on a keyboard type, such that multiple different keyboard types are identified and managed in a single whitelist file or database  114 B. 
     In an embodiment, each separate keyboard type includes its own separate whitelist file or database  114 B. In such a case, an identifier for the keyboard type may be used as the file name or file reference for each whitelist file  114 B, such that when the custom peripheral filter agent  114 A detects and event for a given keyboard type, the keyboard type/identifier can be processed by the custom peripheral filter agent  114 A to locate and retrieve the proper whitelist file  114 A from the files  115 C on the hard drive  115   
     Some of embodiments of the  FIG. 1  and other embodiments are now discussed with reference to the  FIGS. 2-4 . 
       FIG. 2  is a diagram of a method  200  for input peripheral device security, according to an example embodiment. The software module(s) that implements the method  200  is referred to as a “Self-Service Terminal (SST) input device filtering agent.” The SST input device filtering agent is implemented as executable instructions programmed and residing within memory and/or a non-transitory computer-readable (processor-readable) storage medium and executed by one or more processors of a device. The processor(s) of the device that executes the SST input device filtering agent are specifically configured and programmed to process the SST input device filtering agent. The SST input device filtering agent has access to one or more network connections during its processing. The network connections can be wired, wireless, or a combination of wired and wireless. 
     In an embodiment, the device that executes the SST input device filtering agent is the ATM  111  of the  FIG. 1 . 
     In an embodiment, the device that executes the SST input device filtering agent is a kiosk. 
     In an embodiment, the device that executes the SST input device filtering agent is a Point-Of-Sale (POS) terminal. 
     In an embodiment, the SST input device filtering agent is the custom peripheral filter agent  114 A of the  FIG. 1 . 
     In an embodiment, the custom peripheral filter manager  141  is operable to custom-drive and alter the dynamic processing of the SST input device filtering agent without restarting the SST and without altering or modifying the executable instructions of the SST input device filtering agent. 
     At  210 , the SST input device filtering agent intercepts an input command generated from an input peripheral of a host machine. 
     In an embodiment, the SST input device filtering agent hooks into the kernel of the OS to permit intercepting of the input commands emanating from a device driver for the input peripheral. In an embodiment, the hook is a registration with an OS kernel process to pass the input commands from all input peripherals to the SST input device filtering agent. 
     In an embodiment, the host machine is the ATM  111  of the  FIG. 1 . 
     In an embodiment, the host machine is an SST. In an embodiment, the SST is a kiosk. 
     In an embodiment, at  211 , the SST input device filtering agent identifies the input command as a keyboard connected to the host machine through a peripheral port of the host machine. 
     In an embodiment of  211  and at  212 , the SST input device filtering agent recognizes the input command as a sequence of keys activated on the keyboard. In an embodiment the sequence is a single key. In an embodiment the sequence is two or more keys. 
     At  220 , the SST input device filtering agent determines whether to block the input command from being processed by an OS of the host machine or whether to pass the input command to the OS for processing. 
     In an embodiment, at  221 , the SST input device filtering agent attempts to match the input command to a whitelist command file for the input peripheral and when matched, the SST input device filtering agent passes the input command to the OS for processing and when unmatched, the SST input device filtering agent ignores the input command and blocks the input command from being processed by the OS. 
     In an embodiment, the whitelist command file is the whitelist file  114 B of the  FIG. 1 . 
     In an embodiment, at  222 , the SST input device filtering agent identifies a resource that initiated the input command from the input peripheral and the SST input device filtering agent makes the determination based on security rights assigned to the resource with respect to the input command. 
     In an embodiment, the resource is an operator that operates the input peripheral. In an embodiment, the operator is a service engineer that is servicing the SST. 
     In an embodiment, the resource is an automated service or application that can initiate the input command as coming from the input peripheral. 
     In an embodiment of  222  and at  223 , the SST input device filtering agent dynamically obtains the security rights for the resource from a remote network service over a network connection accessible from the host machine. In an embodiment, the remote network service is the custom peripheral filter manager  141  of the  FIG. 1 . In an embodiment, the remote network service is the method  300  discussed with reference to the  FIG. 3  below. 
     In an embodiment of  223  and at  224 , the SST input device filtering agent terminates the security rights when an authenticated session between the host machine and the resource terminates. In an embodiment, the authenticated session is for a resource that is a service engineer performing service on the host machine (SST) pursuant to a service ticket. 
     In an embodiment of  222  and at  225 , the SST input device filtering agent obtains the security rights based on a USB key dongle interfaced to the input peripheral by a service engineer servicing the host machine, where the resource is the service engineer. 
     In embodiment, at  226 , the SST input device filtering agent accesses a whitelist command file to make the determination based on an input peripheral identifier for the input peripheral. In an embodiment, the whitelist command file is the whitelist file  114 B of the  FIG. 1 . 
     In an embodiment, at  230 , the SST input device filtering agent logs a resource identifier for a resource that initiated the input command from the input peripheral when the determination is to block the input command from being processed by the OS of the host machine. This can be used for auditing input commands that were unauthorized and attempted on the host machine through the input peripheral. 
       FIG. 3  is a diagram of another method  300  for input peripheral device security, according to an example embodiment. The software module(s) that implements the method  300  is referred to as an “SST input device filter manager.” The SST input device filter manager is implemented as executable instructions programmed and residing within memory and/or a non-transitory computer-readable (processor-readable) storage medium and executed by one or more processors of a device. The processors that execute the SST input device filter manager are specifically configured and programmed to process the SST input device filter manager. The SST input device filter manager has access to one or more network connections during its processing. The network connections can be wired, wireless, or a combination of wired and wireless. 
     In an embodiment, the device that executes the SST input device filter manager is a server. In an embodiment, the server is the core banking system  140  of the  FIG. 1 . 
     In an embodiment, the device that executes the SST input device filter manager is an SST that is networked to another SST having an instance of the customer peripheral filter agent  114 A of the  FIG. 1  or an instance of the method  200  of the  FIG. 2 . 
     In an embodiment, the SST input device filter manager is the custom peripheral filter manager  141  of the  FIG. 1 . 
     In an embodiment, the SST input device filter manager interacts with the custom peripheral filter agent  114 A of the  FIG. 1  or the method  200  of the  FIG. 2 . 
     In an embodiment, the SST input device filter manager directly interacts with the customer peripheral filter agent  114 A of the  FIG. 1  or the method  200  of the  FIG. 2 . 
     In an embodiment, the SST input device filter manager indirectly interacts with the customer peripheral filter agent  114 A of the  FIG. 1  or the method  200  of the  FIG. 2  through changes to one or more files, such as the whitelist file  114 B and/or configuration files discussed with reference to the  FIG. 1 . 
     In an embodiment, the SST input device filter manager directly interacts and indirectly interacts with the customer peripheral filter agent  114 A of the  FIG. 1  or the method  200  of the  FIG. 2 . 
     At  310 , the SST input device filter manager remotely controls, over a network connection, an agent executing on an SST for enforcing whether the agent permits a key sequence initiated from a keyboard peripheral interfaced to the SST to be processed by the SST. 
     In an embodiment, the agent is the custom peripheral filter agent  114 A of the  FIG. 1 . 
     In an embodiment, the agent is the method  200  of the  FIG. 2 . 
     In an embodiment, the SST is the ATM  111  of the  FIG. 1 . 
     In an embodiment, the SST is a kiosk. 
     In an embodiment, the SST is a POS terminal. 
     According to an embodiment, at  311 , the SST input device filter manager controls the agent through modifications to a whitelist key sequence file that resides on the SST and is processed by the agent. 
     In an embodiment, the whitelist key sequence file is the whitelist file  114 B of the  FIG. 1 . 
     In an embodiment, at  312 , the SST input device filter manager directly controls the agent through interactive instructions sent to the agent and dynamically interpreted and processed by the agent on the SST. 
     In an embodiment, at  313 , the SST input device filter manager indirectly controls the agent through modifications to a file that resides on the SST and is processed by the agent and directly controls the agent through interactive instructions sent to the agent and dynamically interpreted and processed by the agent on the SST. In an embodiment, the file is the whitelist file  114 B of the  FIG. 1 . 
     In an embodiment, at  314 , the SST input device filter manager sets conditions for the agent for dynamic enforcement base at least in part on a resource that initiated the key sequence on the keyboard peripheral. 
     In an embodiment of  314  and at  315 , the SST input device filter manager sets at least one additional condition based on a single communication session between the resource and the SST. 
     In an embodiment of  314  and at  316 , the SST input device filter manager sets at least one additional condition based on a keyboard type associated with the keyboard peripheral. 
       FIG. 4  is a diagram of a SST  400 , according to an example embodiment. The SST  400  includes a variety of hardware components and software components. The software components of the SST  400  are programmed and reside within memory and/or a non-transitory computer-readable medium and execute on one or more processors of the SST  400 . The SST  400  may communicate over one or more networks, which can be wired, wireless, or a combination of wired and wireless. 
     In an embodiment, the SST  400  is the ATM  111  of the  FIG. 1 . 
     In an embodiment, the SST  400  is a kiosk. 
     In an embodiment, the SST  400  is a POS terminal. 
     The SST  400  includes a processor  401  and an input peripheral filter agent  402 . 
     The input peripheral filter agent  402  is adapted and configured to: execute on the processor  401 . 
     In an embodiment, the input peripheral filter agent  402  is the custom peripheral filter agent  114 A of the  FIG. 1 . 
     In an embodiment, the input peripheral filter agent  402  is the method  200  of the  FIG. 2 . 
     In an embodiment, the input peripheral filter agent  402  is further configured to: 1) execute on the processor  401  of the SST  400  and 2) determine whether to pass an input command initiated from an input peripheral to an OS of the SST  400  for processing or whether to block the input command from being passed to the OS for processing. 
     In an embodiment, the input peripheral filter agent  402  is further configured to make the determination based on entries included in a whitelist input command file. In an embodiment, the whitelist input command file is the whitelist file  114 B of the  FIG. 1 . 
     In an embodiment, the SST  400  is the ATM  111  of the  FIG. 1  and a remote network service accessible over a network connection to the ATM  111  at least partially controls the entries to the whitelist input command file over the network connection. In an embodiment, the remote network service is the custom peripheral filter manager  141  of the  FIG. 1 . In an embodiment, the remote network service is the method  300  of the  FIG. 3 . 
     It should be appreciated that where software is described in a particular form (such as a component or module) this is merely to aid understanding and is not intended to limit how software that implements those functions may be architected or structured. For example, modules are illustrated as separate modules, but may be implemented as homogenous code, as individual components, some, but not all of these modules may be combined, or the functions may be implemented in software structured in any other convenient manner. 
     Furthermore, although the software modules are illustrated as executing on one piece of hardware, the software may be distributed over multiple processors or in any other convenient manner. 
     The above description is illustrative, and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of embodiments should therefore be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. 
     In the foregoing description of the embodiments, various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting that the claimed embodiments have more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Description of the Embodiments, with each claim standing on its own as a separate exemplary embodiment.