US20140208107A1 - Systems and methods for implementing application control security - Google Patents
Systems and methods for implementing application control security Download PDFInfo
- Publication number
- US20140208107A1 US20140208107A1 US14/226,294 US201414226294A US2014208107A1 US 20140208107 A1 US20140208107 A1 US 20140208107A1 US 201414226294 A US201414226294 A US 201414226294A US 2014208107 A1 US2014208107 A1 US 2014208107A1
- Authority
- US
- United States
- Prior art keywords
- list
- white
- encrypted
- identifier
- application control
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2153—Using hardware token as a secondary aspect
Definitions
- Application white-lists contain programs that are authorized to run on electronic systems or components of electronic systems, e.g., a computer.
- application white-lists are implemented using a repository of hashes to ensure that a given program on the white-list is authorized to be executed. For example, when a user employs a program on a computer, a hash function verifies that the program is listed in the application white-list as a program authorized to be executed.
- a system includes a first device, a decrypted white-list, and an executable program.
- the first device is in electrical communication with a memory containing an encrypted white-list.
- Executable programs and/or files may be referenced in the encrypted white-list.
- the executable programs and/or files may be inaccessible to unauthorized users when referenced in the encrypted white-list.
- the executable programs and/or files may be referenced in the decrypted white-list.
- the encrypted white-list is decrypted using an identifier of a second device.
- the identifier contains information suitable to identify the second device and may be required to decrypt the encrypted white-list.
- the identifier is in the form of an electromagnetic radiation signal.
- the identifier of the second device may be transmitted to the first device via electromagnetic radiation.
- the electromagnetic radiation signal has a signal strength.
- the identifier is in the form of an electrical signal.
- the second device may be electrically connected to the first device such that the identifier is transmitted via an electrical connection between the first device and second device.
- the encrypted white-list is decrypted using an identifier of a third device.
- the identifier is received at the first device from a biometric reader.
- the identifier of the second device and the identifier of the third device are combined to create a composite identifier.
- the encrypted white-list has at least two partitions.
- a first partition may have executable programs with a first level of security and a second partition may have executable programs with a second level of security.
- the first partition may be decrypted using an identifier that is different than the identifier used to decrypt the second partition.
- a method may comprise receiving at a first device an identifier of a second device, where the first device is operable to read an encrypted white-list, receiving the encrypted white-list, producing a decrypted white-list, determining whether an executable program is referenced in the decrypted white-list, and based on the determining step, allowing or disallowing execution of the executable program.
- the producing step comprises decrypting the encrypted white-list using the identifier of the second device.
- the first device and the second device may have access to a network and the method may further comprise transmitting a request onto the network.
- the method may further comprise performing the receiving at a first device an identifier of a second device step in response to the transmitting step.
- the request is an address resolution protocol.
- the receiving at a first device an identifier of a second device step may comprise receiving the identifier in the form of an electromagnetic radiation signal.
- the electromagnetic radiation signal has a signal strength.
- the method may further comprise determining whether the signal strength is above a predetermined threshold, in one embodiment, the method may further comprise receiving an indication that the signal strength is no longer above the predetermined threshold, and based on the receiving an indication step, deleting the decrypted white-list.
- the method may further comprise disallowing, prior to the receiving at a first device an identifier of a second device step, execution of the executable program on the first device.
- the method may further comprise creating a white-list associated with the second device, receiving the identifier of the second device, encrypting the white-list via the identifier of the second device, and storing the encrypted white-list in the memory.
- the method may further comprise transmitting, prior to the receiving at a first device an identifier of a second device step, an identifier of the first device to the second device.
- the receiving at a first device an identifier of a second device step may comprise receiving the identifier in the form of an electrical signal.
- the identifier is received from a biometric reader.
- the method may further comprise partitioning the encrypted white-list into at least two partitions, and decrypting at least one partition of the encrypted white-list using the identifier of the second device.
- the first device receives the encrypted white-list from a memory in electrical communication with the first device.
- deleting the encrypted white-list comprises deleting the encrypted white-list from the memory.
- a method comprises receiving at a first device an identifier of a second device and an identifier of a third device, where the first device is operable to read an encrypted white-list, receiving the encrypted white-list, creating a composite identifier using the identifier of the second device and the identifier of the third device, producing a decrypted white-list, determining whether an executable program is referenced in the decrypted white-list, and based on the determining step, allowing or disallowing execution of the executable program.
- the producing step may comprise decrypting the encrypted white-list using the composite identifier.
- FIG. 1 is a schematic view of one embodiment of a system useful in accordance with the present disclosure.
- FIG. 2 is a schematic view of one embodiment of a system useful in accordance with the present disclosure.
- FIG. 3 is a flow chart of one embodiment of methods useful for implementing application control security.
- FIG. 4 is a flow chart of one embodiment of methods useful for handling encrypted and decrypted white-lists.
- FIG. 5 is a schematic view of one embodiment of a system useful for handling white-lists in accordance with the present disclosure.
- FIG. 6 is a flow chart of one embodiment of methods of managing access to an executing device including generation of an encrypted white-list.
- the present application relates to systems and methods for implementing application control security.
- a system useful for implementing application control security is illustrated in FIG. 1 .
- the system 100 includes a server 110 and an executing device 200 .
- the executing device 200 may be useful for running executable programs 260 .
- the executing device 200 includes a local store 210 , a request handler 220 , and a white-list 230 .
- the server 110 may be in communication (e.g., electrical communication., such as wired or wireless communication) with the executing device 200 , such as one or more of a computer, server, mobile phone, and personal digital assistant (PDA), to name a few.
- PDA personal digital assistant
- the server 110 may be in communication with the request handler 220 .
- a request message to build the white-list 230 may be sent by an administrator (not illustrated) from the server 110 to the request handler 220 .
- the request handler 220 saves the white-list 230 configuration in the local store 210 .
- the process of building the white-list 230 includes registering a list of executable programs 260 in the white-list 230 .
- a white-list is a list located in memory of a computer and that contains a list of executable programs, e.g., software applications that are authorized to run on a device.
- application white-lists are implemented using a repository of cryptographic hashes to ensure that a given program on the white-list is authorized to be executed. For example, when a user employs a program on a computer, a cryptographic hash function verifies that the program is listed in the application white-list as a program authorized to be executed.
- users and/or computers are in white-list-only mode, any unauthorized executable is prevented from loading and executing.
- White-list-only mode prevents all unauthorized executables from loading and being executed,
- the executing device 200 includes memory 250 , which may contain an encrypted white-list 240 .
- the encrypted white-list 240 may be encrypted using all or part of an identifier 310 of an application control device 300 .
- hash information of the encrypted white-list 240 may be transformed with the identifier 310 of the application control device 300 to make the encrypted white-list 240 inaccessible to non-authorized users.
- control device 300 to encrypt the white-list 240 may mitigate theft of data.
- a device is an electrical system and/or a component of an electronic system.
- a device may be a computer, server, mobile phone, personal digital assistant (PDA), cordless communicator, e.g., a Bluetooth device, a wireless service point, a biometric reader, a dongle, or an authorized user's badge, to name a few.
- PDA personal digital assistant
- cordless communicator e.g., a Bluetooth device, a wireless service point, a biometric reader, a dongle, or an authorized user's badge, to name a few.
- the memory 250 containing the encrypted white-list 240 may be in electrical communication with the executing device 200 .
- the executing device 200 includes a memory 250 that contains an encrypted white-list 240 .
- Memory is a component of an electronic system used to store information (e.g., on a temporary or permanent basis).
- memory may include read-only memory (ROM) (e.g., PROM, EPROM, EEPROM, EAROM, Flash memory) or read-write memory (e.g., random access memory, hard disk drive, solid state drive), to name a few.
- ROM read-only memory
- PROM PROM
- EPROM e.g., EPROM, EEPROM, EAROM, Flash memory
- read-write memory e.g., random access memory, hard disk drive, solid state drive
- the memory 250 containing the encrypted white-list 240 may be located on any device, e.g., a device different than the executing device 200 .
- the memory 250 containing the encrypted white-list 240 may be separate from and in electrical communication with the executable device 200 .
- the white-list (e.g., encrypted or decrypted) is stored in a computer memory and accessed via electrical communication.
- the white-list (e.g., encrypted or decrypted) is stored in other types of data storage such as on optical disc, magnetic tape and accessed or read via another machine readable format.
- the white-list could be in the form of a 2D barcode which is optically scanned or read.
- the executing device 200 is operable to read and/or receive the white-list.
- the white-list 230 contains a list of executable programs 260 .
- an executable program e.g., 260 1
- the white-list is reviewed and permission must be granted.
- an administrator of the executing device 200 may grant permission to allow the executable program 260 1 to be executed.
- the encrypted white-list 240 may be decrypted.
- the encrypted white-list 240 may be decrypted using the identifier 310 of the application control device 300 .
- An identifier is any information suitable to identify (e.g., uniquely identify) a device.
- the identifier 310 may be a network identifier, the name of the device, an ID of the device, or RFID, to name a few.
- the application control device 300 may be mobile.
- the application control device 300 may be capable of moving readily.
- a mobile application control device 300 may include at least one of a cell phone, a device supporting the Bluetooth protocol, and an ID badge, to name a few.
- the identifier 310 of the application control device 300 may be transmitted to an executing device 200 by the application control device 300 during normal operation of the application control device 300 .
- the executing device 200 may receive the identifier 310 during normal operation of the executing device 200 .
- the application control device 300 may receive a signal, e.g., a radio frequency signal, to trigger, induce, and/or provoke transmission of the identifier 310 to the executing device 200 .
- the card reader module may transmit a signal to the ID badge to trigger, induce, and/or provoke transmission of the identifier 310 of the ID badge (e.g., an RFID badge).
- the ID badge e.g., an RFID badge
- the application control device 300 may be in a fixed location.
- the application control device 300 may be a wireless LAN.
- the identifier 310 may be an SSID of a wireless LAN.
- the SSID is transmitted to the executing device 200 , e.g., a laptop.
- the application control device 300 may be physically connected to the executing device 200 .
- the application control device 300 may be a flash drive or a dongle, to name a few.
- the identifier 310 of the application control device 300 may be a software file.
- the identifier 310 of the application control device 300 may be a number programmed into memory of the application control device 300 .
- the software file and/or the number programmed into memory may be created and/or programmed by the owner of the application control device 300 and may be any identifier 310 the owner chooses.
- the application control device 300 may be part of the executable device 200 .
- the application control device 300 may be a biometric reader.
- the biometric reader may be located in the executable device 200 .
- the identifier 310 of the application control device 300 may be an electrical signal converted from a finger print of an authorized user.
- the identifier 310 may be in the form of an electromagnetic radiation signal.
- the application control device 300 may be a Bluetooth device, and the executing device 200 may be a phone, smartphone, or PDA.
- the identifier 310 is transmitted via electromagnetic radiation from the application control device 300 to the executing device 200 .
- the electromagnetic radiation signal may have a signal strength.
- the identifier 310 may be a MAC address of the application control device 300 .
- the identifier 310 may be received at the executing device 200 due to the executing device 200 polling the application control device 300 for the MAC address.
- the identifier 310 is in the form of an electrical signal.
- an application control device 300 may be electrically connected to the executing device 200 .
- the identifier 310 may be a programmable software key that is transmitted via an electrical connection from the application control device 300 to the executing device 200 .
- a flash drive and/or a dongle may be physically connected to the executing device 200 and may contain a programmable software key that is read by the executing device 200 and used to decrypt the encrypted white-list 240 .
- the application control device 300 may be a biometric reader electrically connected to the executing device 200 .
- the identifier 310 may be an electrical signal converted from a finger print of an authorized user.
- the finger print of the authorized user may be converted to an electrical signal every 15 minutes.
- an authorized user may be required to apply their finger to the biometric reader every 15 minutes in order to decrypt the encrypted white-list 240 .
- FIG. 3 shows a flowchart of a method for providing application control security.
- the method includes receiving a request for execution of an executable program in step 510 .
- the decrypted white-list is checked to see if the executable program is referenced therein in step 512 . If the executable program is referenced in the decrypted white-list, execution of the executable program is allowed in step 514 . If the executable program is not referenced in the decrypted white-list, execution of the executable program is not allowed in step 516 .
- the decrypted white-list may be restricted by a time to live (TTL) so that the white-list remains decrypted, for example, for only one TTL period.
- TTL time to live
- the executing device may delete the decrypted white-list and require the identifier to be received again.
- the TTL is a configurable value.
- the TTL may be downloaded to the executing device from the server.
- FIG. 4 is a flow chart of one embodiment of methods useful for handling encrypted and decrypted white-lists.
- the method includes receiving the identifier of the application control device in step 610 .
- the identifier of the application control device, or a portion thereof, as described further herein, is used to create the encrypted white-list in step 612 .
- steps 610 and 612 may be performed by the executing device.
- the executing device may be operated by a user with permission to control application white-lists (e.g., an administrator) while an identifier of an application control device is received by the executing device in step 610 (e.g., via placing a cordless application control device in proximity to the executing device) and a white-list is encrypted using the identifier in step 612 (e.g., by direction of the administrator).
- steps 610 and 612 may be performed by a server or device separated from the executing device.
- a user with permission to control application white-lists may operate a server or other device separated from the executing device to receive an identifier of an application control device in step 610 and to create an encrypted white-list using the identifier in step 612 .
- the identifier may be received in step 610 at a device different from a device on which the encrypted white-list is created.
- the identifier is received in step 610 by the executing device (e,g., in administrator mode) and is transmitted to a server for the server to encrypt a white-list in step 612 .
- the executing device may be operated to initially collect an identifier of the application control device and the server may maintain a repository of encrypted white-lists to serve to executing devices.
- the identifier of the application control device is received in step 610 at a server and passed to the executing device.
- the identifier may subsequently be downloaded from the server to the executing device to be used in encrypting a white-list in step 612 on the executing device, such as when the executing device is in an administrator mode.
- the executing device may read the identifier of the application control device from the server and create an encrypted white-list.
- the encrypted white-list may be restricted by a time to live (TTL).
- the method uses a TTL timer to determine the TTL of a decrypted white-list stored in a cache.
- the TTL timer is initialized in step 614 .
- the TTL timer is configured by a server and downloaded by the executing device. For example, the TTL timers of multiple executing devices may be controlled by a central device separate from the executing device.
- the method uses a polling timer to determine an interval by which to request, poll, scan, and/or survey identifiers of application control devices that are available to the executing device.
- the duration of the polling timer is configured at the server and downloaded to the executing device. After the polling timer is initialized with an initial duration in step 616 , the method includes checking if it is time to poll for the identifier of the application control device in step 618 . If it is not time to poll for the identifier of the application control device, step 618 is repeated until it is time to poll for the identifier of the application control device.
- the executing device may collect and/or receive at least one identifier of at least one application control device in step 620 .
- the executing device may check for the presence of the correct identifier to ensure that an authorized user is still near. For example, if the application control device is a mobile phone of an authorized user, the executing device will check to see if it has received the identifier of the mobile phone (e.g., an identifier of the mobile phone that is part of a Bluetooth network). If the identifier of the mobile phone is received, the white-list remains decrypted.
- the application control device is an authorized user's ID badge
- the executing device will transmit a signal to trigger, induce, and/or provoke transmission of the identifier of the authorized user's ID badge. If the identifier of the authorized user's ID badge is received, the white-list will remain decrypted.
- one identifier of one application control device is collected in step 620 .
- at least two identifiers of at least two application control devices are collected, or at least three identifiers of at least three application control devices are collected, or at least four identifiers of at least four application control devices are collected, or at least five identifiers of at least five application control devices are collected.
- the encrypted white-list is attempted to be decrypted using the at least one identifier collected and the decryption results are stored into cache.
- the decryption results are filtered, checked and/or analyzed to confirm that only correct decryptions are stored. For example, encrypted white-lists that yield improper or non-functioning results (e.g., decrypted white-lists) after decryption may not be stored.
- all decryption results from collected identifiers and encrypted white-lists are stored (e.g., including results from attempted decryptions using an incorrect application control device identifier).
- a cache may store incorrect results that, when the cached results are reviewed in response to a request to execute an executable (e.g., in an attempt to run the executing device in white-list-only mode), the executing device will not allow the executable to execute.
- the correct identifier is not collected in step 620 , then the encrypted white-list is not decrypted.
- the results of the decryption may be checked to see if the decryption succeeded (e.g., in a usable decrypted white-list).
- the TTL timer is step 614 is reset to its initial value. In one embodiment, if a correct identifier is collected, the polling timer is reset to its initial value. In one embodiment, the TTL timer is periodically checked to see if the timer has expired. If the TTL timer has expired, the decrypted white-list may be deleted (e.g., from a cache Mere white-lists are checked).
- FIG. 5 is a schematic view of one embodiment of a system useful for handling white-lists in accordance with the present disclosure.
- the identifier 310 of the application control device 300 may be transmitted to the executing device 200 .
- the wireless LAN may include an SSID received by the laptop.
- a transmitter of the wireless LAN e.g., wireless access point
- the executing device 200 may poll the application control device 300 for the identifier 310 . In one embodiment, the executing device 200 may poll the application control device 300 , at the polling time, for the identifier 310 at least once a second. In some embodiments, the executing device 200 may poll the application control device 300 for the identifier 310 at least once every five seconds, or at least once every 10 seconds, or at least once every minute, or at least once every 10 minutes, or at least once every hour. For example, if the application control device 300 is a Bluetooth device and the executing device 200 is a mobile smartphone, the smartphone may poll the Bluetooth device for the identifier 310 at least once every minute.
- the encrypted white-list 240 may be partitioned. In one embodiment, the encrypted white-list 240 has at least two partitions. For example, a first partition of the encrypted white-list 240 may have executable programs 260 with a minimal level of security requirement such as an operating system or applications related thereto. In one embodiment, the first partition may be decrypted using a first key that is available as an identifier of a wireless LAN transmitter (e.g., a wireless access point) located in a building.
- a wireless LAN transmitter e.g., a wireless access point
- a second partition of the encrypted white-list 240 may have executable programs 260 with a higher-level of security, such as a word processing application (e.g., Microsoft Office tools), or a company's VPN (Virtual Private Network) access, to name a few.
- the identifier 310 may be used to decrypt one partition of the encrypted white-list 240 . For example, if the identifier 310 is used to encrypt and decrypt the first partition of the encrypted white-list 240 , operating system applications may be executed, but Microsoft Office tools and a companies VPN access may not be executed and/or accessed.
- the first partition of the encrypted white-list 240 is not encrypted, thereby allowing the operating system to boot in the executing device 200 regardless of whether there is an identifier 310 received at the executing device 200 .
- the identifier 310 is used to encrypt and decrypt the second partition of the encrypted white-list 240 , but there is no identifier of the first partition of the encrypted white-list 240 , then operating system applications may not be executed resulting in the executing device 200 denying access to the device entirely.
- each partition may reference the type of application control device 300 used to encrypt the partition.
- operating system applications may be referenced in an un-encrypted white-list, e.g., the identifier 310 would not be required to start the operation system applications.
- more than one white-list 240 may be utilized.
- a first white-list may contain a list of operating system applications available to anyone with access to the executing device 200
- a second white-list may contain Microsoft Office tools available to all employees of a company
- a third white-list may contain applications available only to managers of the company.
- a first identifier may be required to access the Microsoft Office tools and a second identifier may be required to access the applications available only to managers. This may apply to a partitioned white-list as well.
- the encrypted white-list 240 may be encrypted by all or part of a composite identifier 450 , composed of a combination of the identifier 310 of the application control device 300 and an identifier 410 of a second application control device 400 .
- a composite identifier 450 may be used to encrypt and decrypt the white-list 230 .
- both the identifier 310 and the identifier 410 may be received at the executing device 200 from the first and second application control devices 300 and 400 and used to form a composite identifier 450 for use in decrypting an encrypted white-list.
- the composite identifier 450 may allow execution and/or access to all the executable programs 260 referenced in the encrypted white-list 240 . In one embodiment, the composite identifier 450 may allow execution and/or access to only some of the executable programs 260 referenced in the encrypted white-list 240 . For example, the composite identifier 450 may serve to decrypt certain partitions of the encrypted white-list 240 , but not others.
- the executing device 200 may be required to be in a particular location before the encrypted white-list 240 may be decrypted.
- the application control device 300 may be a GPS device in communication with a plurality of GPS satellites, and the identifier 310 may be GPS information received from the GPS device.
- the identifier 310 received may be longitude and latitude data. (e.g., a location, a range of locations) indicating where the executing device 200 is permitted to be while it is executing certain executables on a partition of the encrypted white-list 240 or an individual encrypted white-list 240 .
- the application control device 300 may be a mobile phone and the identifier 310 may be location information of the mobile phone, such as information related to a cellular tower used by the mobile phone.
- a second application control device 400 may be required to decrypt the encrypted white-list 240 .
- the executing device 200 may additionally require the identifier 410 of the second application control device 400 to decrypt the encrypted white-list or a partition thereof.
- the present disclosure may mitigate theft of data because even if the executing device 200 is stolen, without the presence of at least one of the application control devices 300 / 400 the executable programs 260 referenced in the encrypted white-list 240 will not execute, and in some cases, the executing device 200 may not boot at all.
- the composite identifier 450 may include multiple identifiers of multiple application control devices in order to encrypt and decrypt the white-list 230 and for the executing device 200 to allow execution of authorized executables.
- the composite identifier 450 may include at least 3 identifiers of at least 3 application control devices.
- the composite identifier 450 may include at least 4 identifiers of at least 4 application control devices, or at least 5, or at least 6. More identifiers and application control devices may be used.
- FIG. 6 is a flow chart of one embodiment of methods of managing access to an executing device including generation of an encrypted white-list.
- one or more white-list(s) may need to have their encryption modified (e.g., re-encrypted) or may need to be recovered, repaired, and/or replaced if the executing device loses functionality in one or more white-lists (e.g., device malfunctions, device experiences memory error).
- the method includes requesting a reduction (e.g., a “step down”) of the encryption of the encrypted white-list in step 710 .
- an administrator may request that a white-list or a partition thereof be decrypted and re-encrypted with a new identifier (e.g., an identifier of another application control device).
- a new identifier e.g., an identifier of another application control device.
- an administrator may request that a first encrypted white-list be replaced with a second encrypted white-list.
- an entire white-list on an executing device or a partition of the encrypted white-list may be re-encrypted, recovered, repaired, and/or replaced.
- a white-list or partition of a white-list may be replaced with another white-list with a lower level of encryption, or with no encryption at all.
- one partition of the encrypted white-list may be “stepped down” to a second partition of the encrypted white-list with a lower level of encryption.
- the white-list may be “stepped down” to a lower level of encryption through receiving the request in step 712 and attempt to decrypt the white-list in step 714 .
- the encrypted white-list may be re-created via encrypting the white-list.
- the white-list may be re-encrypted with a new identifier.
- the white-list may be encrypted using a new identifier provided by a server.
- the white-list may be left decrypted.
- an administrator may determine that a white-list or a partition thereof should not be encrypted. After the white-list is encrypted in step 718 or if the white-list is determined in step 716 not to be re-encrypted, the new white-list with modified encryption (or lack of encryption) is provided in step 720 .
- a server may receive the white-list for distribution, such as to an executing device.
Abstract
Description
- This application is a continuation of U.S. patent application Ser. No. 13/269,040, filed Oct. 7, 2011, which claims priority to U.S. Patent Application No. 61/392,022, filed Oct. 11, 2010, both entitled “SYSTEMS AND METHODS FOR IMPLEMENTING APPLICATION CONTROL SECURITY,” which are incorporated herein by reference in their entirety.
- Application white-lists contain programs that are authorized to run on electronic systems or components of electronic systems, e.g., a computer. Generally, application white-lists are implemented using a repository of hashes to ensure that a given program on the white-list is authorized to be executed. For example, when a user employs a program on a computer, a hash function verifies that the program is listed in the application white-list as a program authorized to be executed.
- Broadly, the present disclosure relates to systems, methods, and apparatus for implementing application control security. The systems, methods, and apparatus disclosed herein, may be useful to mitigate theft of data (e.g., from a device). In one aspect, a system includes a first device, a decrypted white-list, and an executable program. The first device is in electrical communication with a memory containing an encrypted white-list. Executable programs and/or files may be referenced in the encrypted white-list. The executable programs and/or files may be inaccessible to unauthorized users when referenced in the encrypted white-list. In order for the executable programs and/or files to be accessed, the executable programs and/or files may be referenced in the decrypted white-list. In this regard, the encrypted white-list is decrypted using an identifier of a second device. The identifier contains information suitable to identify the second device and may be required to decrypt the encrypted white-list. Thus, if the first device, e.g., a laptop, gets stolen without the second device, i.e., the identifier of the second device is not available to decrypt the encrypted white-list, all executable programs and/or files referenced in the encrypted white-list will be inaccessible to the thief This results in mitigation of data loss due to theft.
- In one approach, the identifier is in the form of an electromagnetic radiation signal. For example, the identifier of the second device may be transmitted to the first device via electromagnetic radiation. In one embodiment, the electromagnetic radiation signal has a signal strength. In another approach, the identifier is in the form of an electrical signal. For example, the second device may be electrically connected to the first device such that the identifier is transmitted via an electrical connection between the first device and second device. In one approach, the encrypted white-list is decrypted using an identifier of a third device. In one embodiment, the identifier is received at the first device from a biometric reader. In on embodiment, the identifier of the second device and the identifier of the third device are combined to create a composite identifier. In one approach, the encrypted white-list has at least two partitions. For example, a first partition may have executable programs with a first level of security and a second partition may have executable programs with a second level of security. In another example, the first partition may be decrypted using an identifier that is different than the identifier used to decrypt the second partition.
- Methods for implementing application control security are provided. In one embodiment, a method may comprise receiving at a first device an identifier of a second device, where the first device is operable to read an encrypted white-list, receiving the encrypted white-list, producing a decrypted white-list, determining whether an executable program is referenced in the decrypted white-list, and based on the determining step, allowing or disallowing execution of the executable program. In one embodiment, the producing step comprises decrypting the encrypted white-list using the identifier of the second device.
- In one embodiment, the first device and the second device may have access to a network and the method may further comprise transmitting a request onto the network. In one embodiment, the method may further comprise performing the receiving at a first device an identifier of a second device step in response to the transmitting step. In one embodiment, the request is an address resolution protocol. In one embodiment, the receiving at a first device an identifier of a second device step may comprise receiving the identifier in the form of an electromagnetic radiation signal. In one embodiment, the electromagnetic radiation signal has a signal strength. In one embodiment, the method may further comprise determining whether the signal strength is above a predetermined threshold, in one embodiment, the method may further comprise receiving an indication that the signal strength is no longer above the predetermined threshold, and based on the receiving an indication step, deleting the decrypted white-list.
- In one embodiment, the method may further comprise disallowing, prior to the receiving at a first device an identifier of a second device step, execution of the executable program on the first device. In one embodiment, the method may further comprise creating a white-list associated with the second device, receiving the identifier of the second device, encrypting the white-list via the identifier of the second device, and storing the encrypted white-list in the memory. In one embodiment, the method may further comprise transmitting, prior to the receiving at a first device an identifier of a second device step, an identifier of the first device to the second device. In one embodiment, the receiving at a first device an identifier of a second device step may comprise receiving the identifier in the form of an electrical signal. In one embodiment, the identifier is received from a biometric reader.
- In one embodiment, the method may further comprise partitioning the encrypted white-list into at least two partitions, and decrypting at least one partition of the encrypted white-list using the identifier of the second device. In one embodiment, the first device receives the encrypted white-list from a memory in electrical communication with the first device. In one embodiment, deleting the encrypted white-list comprises deleting the encrypted white-list from the memory.
- In one embodiment, a method comprises receiving at a first device an identifier of a second device and an identifier of a third device, where the first device is operable to read an encrypted white-list, receiving the encrypted white-list, creating a composite identifier using the identifier of the second device and the identifier of the third device, producing a decrypted white-list, determining whether an executable program is referenced in the decrypted white-list, and based on the determining step, allowing or disallowing execution of the executable program. In one embodiment, the producing step may comprise decrypting the encrypted white-list using the composite identifier.
- Various ones of the unique aspects, approaches, and embodiments noted herein above may be combined to yield various systems, methods, and apparatus configured to implement application control security. Furthermore, the above-described systems may be utilized in conjunction with the above-described methods, and vice-versa, as appropriate, to achieve various inventive systems, methods, and apparatus for implementing application control security.
- These and other aspects and advantages, and novel features of this new technology are set forth in part in the description that follows and will become apparent to those skilled in the art upon examination of the following description and figures, or may be learned by practicing one or more embodiments of the technology provided for by the present disclosure.
-
FIG. 1 is a schematic view of one embodiment of a system useful in accordance with the present disclosure. -
FIG. 2 is a schematic view of one embodiment of a system useful in accordance with the present disclosure. -
FIG. 3 is a flow chart of one embodiment of methods useful for implementing application control security. -
FIG. 4 is a flow chart of one embodiment of methods useful for handling encrypted and decrypted white-lists. -
FIG. 5 is a schematic view of one embodiment of a system useful for handling white-lists in accordance with the present disclosure. -
FIG. 6 is a flow chart of one embodiment of methods of managing access to an executing device including generation of an encrypted white-list. - Reference will now be made in detail to the accompanying drawings, which at least assist in illustrating various pertinent embodiments of the new technology provided for by the present disclosure.
- Broadly, the present application relates to systems and methods for implementing application control security. One embodiment of a system useful for implementing application control security is illustrated in
FIG. 1 . In the illustrated embodiment, thesystem 100 includes aserver 110 and anexecuting device 200. The executingdevice 200 may be useful for runningexecutable programs 260. The executingdevice 200 includes alocal store 210, arequest handler 220, and a white-list 230. In one embodiment, theserver 110 may be in communication (e.g., electrical communication., such as wired or wireless communication) with the executingdevice 200, such as one or more of a computer, server, mobile phone, and personal digital assistant (PDA), to name a few. In one embodiment, theserver 110 may be in communication with therequest handler 220. A request message to build the white-list 230 may be sent by an administrator (not illustrated) from theserver 110 to therequest handler 220. In one embodiment, therequest handler 220 saves the white-list 230 configuration in thelocal store 210. In one embodiment, the process of building the white-list 230 includes registering a list ofexecutable programs 260 in the white-list 230. - A white-list is a list located in memory of a computer and that contains a list of executable programs, e.g., software applications that are authorized to run on a device. Generally, application white-lists are implemented using a repository of cryptographic hashes to ensure that a given program on the white-list is authorized to be executed. For example, when a user employs a program on a computer, a cryptographic hash function verifies that the program is listed in the application white-list as a program authorized to be executed. When users and/or computers are in white-list-only mode, any unauthorized executable is prevented from loading and executing. White-list-only mode prevents all unauthorized executables from loading and being executed,
- In one embodiment, and with reference now to
FIG. 2 , the executingdevice 200 includesmemory 250, which may contain an encrypted white-list 240. The encrypted white-list 240 may be encrypted using all or part of anidentifier 310 of anapplication control device 300. For example, hash information of the encrypted white-list 240 may be transformed with theidentifier 310 of theapplication control device 300 to make the encrypted white-list 240 inaccessible to non-authorized users. Using theidentifier 310 of the application,control device 300 to encrypt the white-list 240 may mitigate theft of data. - A device is an electrical system and/or a component of an electronic system. For example, a device may be a computer, server, mobile phone, personal digital assistant (PDA), cordless communicator, e.g., a Bluetooth device, a wireless service point, a biometric reader, a dongle, or an authorized user's badge, to name a few. In one embodiment, the
memory 250 containing the encrypted white-list 240 may be in electrical communication with the executingdevice 200. - As described further herein, the executing
device 200 includes amemory 250 that contains an encrypted white-list 240. Memory is a component of an electronic system used to store information (e.g., on a temporary or permanent basis). For example, memory may include read-only memory (ROM) (e.g., PROM, EPROM, EEPROM, EAROM, Flash memory) or read-write memory (e.g., random access memory, hard disk drive, solid state drive), to name a few. In one embodiment, thememory 250 containing the encrypted white-list 240 may be located on any device, e.g., a device different than the executingdevice 200. In one embodiment, thememory 250 containing the encrypted white-list 240 may be separate from and in electrical communication with theexecutable device 200. - In one embodiment, the white-list (e.g., encrypted or decrypted) is stored in a computer memory and accessed via electrical communication. In another embodiment, the white-list (e.g., encrypted or decrypted) is stored in other types of data storage such as on optical disc, magnetic tape and accessed or read via another machine readable format. For example, the white-list could be in the form of a 2D barcode which is optically scanned or read. In one embodiment, when whatever data storage medium or mechanism for obtaining the white-list is invoked, the executing
device 200 is operable to read and/or receive the white-list. - As shown in
FIG. 1 , the white-list 230 contains a list ofexecutable programs 260. Before an executable program, e.g., 260 1, can be executed by the executingdevice 200 in white-list-only mode, the white-list is reviewed and permission must be granted. In one embodiment, an administrator of the executingdevice 200 may grant permission to allow theexecutable program 260 1 to be executed. In one embodiment, before permission can be granted to execute theexecutable program 260 1, the encrypted white-list 240 may be decrypted. In one embodiment, and with reference now toFIG. 2 , the encrypted white-list 240 may be decrypted using theidentifier 310 of theapplication control device 300. An identifier is any information suitable to identify (e.g., uniquely identify) a device. For example, theidentifier 310 may be a network identifier, the name of the device, an ID of the device, or RFID, to name a few. - In one embodiment, the
application control device 300 may be mobile. For example, theapplication control device 300 may be capable of moving readily. In one embodiment, a mobileapplication control device 300 may include at least one of a cell phone, a device supporting the Bluetooth protocol, and an ID badge, to name a few. In one embodiment, theidentifier 310 of theapplication control device 300 may be transmitted to an executingdevice 200 by theapplication control device 300 during normal operation of theapplication control device 300. In this example, the executingdevice 200 may receive theidentifier 310 during normal operation of the executingdevice 200. In one embodiment, theapplication control device 300 may receive a signal, e.g., a radio frequency signal, to trigger, induce, and/or provoke transmission of theidentifier 310 to the executingdevice 200. For example, if the executingdevice 200 is a computer including a card reader module and theapplication control device 300 is an ID badge, the card reader module may transmit a signal to the ID badge to trigger, induce, and/or provoke transmission of theidentifier 310 of the ID badge (e.g., an RFID badge). - In one embodiment, the
application control device 300 may be in a fixed location. For example, theapplication control device 300 may be a wireless LAN. In one embodiment, theidentifier 310 may be an SSID of a wireless LAN. In this example, the SSID is transmitted to the executingdevice 200, e.g., a laptop. - In one embodiment, the
application control device 300 may be physically connected to the executingdevice 200. For example, theapplication control device 300 may be a flash drive or a dongle, to name a few. In one embodiment, theidentifier 310 of theapplication control device 300 may be a software file. In one embodiment, theidentifier 310 of theapplication control device 300 may be a number programmed into memory of theapplication control device 300. In one embodiment, the software file and/or the number programmed into memory may be created and/or programmed by the owner of theapplication control device 300 and may be anyidentifier 310 the owner chooses. - In one embodiment, the
application control device 300 may be part of theexecutable device 200. For example, theapplication control device 300 may be a biometric reader. In one embodiment, the biometric reader may be located in theexecutable device 200. In one embodiment, theidentifier 310 of theapplication control device 300 may be an electrical signal converted from a finger print of an authorized user. - In one embodiment, the
identifier 310 may be in the form of an electromagnetic radiation signal. For example, theapplication control device 300 may be a Bluetooth device, and the executingdevice 200 may be a phone, smartphone, or PDA. In this example, theidentifier 310 is transmitted via electromagnetic radiation from theapplication control device 300 to the executingdevice 200. In one embodiment, the electromagnetic radiation signal may have a signal strength. In one embodiment, theidentifier 310 may be a MAC address of theapplication control device 300. In this example, theidentifier 310 may be received at the executingdevice 200 due to the executingdevice 200 polling theapplication control device 300 for the MAC address. - In one embodiment, the
identifier 310 is in the form of an electrical signal. In one example, anapplication control device 300 may be electrically connected to the executingdevice 200. In this example, theidentifier 310 may be a programmable software key that is transmitted via an electrical connection from theapplication control device 300 to the executingdevice 200. For example, a flash drive and/or a dongle may be physically connected to the executingdevice 200 and may contain a programmable software key that is read by the executingdevice 200 and used to decrypt the encrypted white-list 240. In another example, theapplication control device 300 may be a biometric reader electrically connected to the executingdevice 200. In this example, theidentifier 310 may be an electrical signal converted from a finger print of an authorized user. In one embodiment, the finger print of the authorized user may be converted to an electrical signal every 15 minutes. In one embodiment, an authorized user may be required to apply their finger to the biometric reader every 15 minutes in order to decrypt the encrypted white-list 240. -
FIG. 3 shows a flowchart of a method for providing application control security. In one embodiment, the method includes receiving a request for execution of an executable program instep 510. Before the executable program can be executed, the decrypted white-list is checked to see if the executable program is referenced therein instep 512. If the executable program is referenced in the decrypted white-list, execution of the executable program is allowed instep 514. If the executable program is not referenced in the decrypted white-list, execution of the executable program is not allowed instep 516. - After the encrypted white-list is decrypted, the decrypted white-list may be restricted by a time to live (TTL) so that the white-list remains decrypted, for example, for only one TTL period. For example, after the encrypted white-list is decrypted, it may stay in cache for the TTL. In one embodiment, as described further herein, once the TTL expires, the executing device may delete the decrypted white-list and require the identifier to be received again. In one embodiment, the TTL is a configurable value. For example, the TTL may be downloaded to the executing device from the server.
-
FIG. 4 is a flow chart of one embodiment of methods useful for handling encrypted and decrypted white-lists. In one embodiment, the method includes receiving the identifier of the application control device instep 610. The identifier of the application control device, or a portion thereof, as described further herein, is used to create the encrypted white-list instep 612. In one embodiment, steps 610 and 612 may be performed by the executing device. For example, the executing device may be operated by a user with permission to control application white-lists (e.g., an administrator) while an identifier of an application control device is received by the executing device in step 610 (e.g., via placing a cordless application control device in proximity to the executing device) and a white-list is encrypted using the identifier in step 612 (e.g., by direction of the administrator). In another embodiment, steps 610 and 612 may be performed by a server or device separated from the executing device. For example, a user with permission to control application white-lists may operate a server or other device separated from the executing device to receive an identifier of an application control device instep 610 and to create an encrypted white-list using the identifier instep 612. - In some embodiments, the identifier may be received in
step 610 at a device different from a device on which the encrypted white-list is created. In one embodiment, the identifier is received instep 610 by the executing device (e,g., in administrator mode) and is transmitted to a server for the server to encrypt a white-list instep 612. For example, the executing device may be operated to initially collect an identifier of the application control device and the server may maintain a repository of encrypted white-lists to serve to executing devices. In another embodiment, the identifier of the application control device is received instep 610 at a server and passed to the executing device. For example, the identifier may subsequently be downloaded from the server to the executing device to be used in encrypting a white-list instep 612 on the executing device, such as when the executing device is in an administrator mode. The executing device may read the identifier of the application control device from the server and create an encrypted white-list. - In one embodiment, after the encrypted white-list is created in
step 612, the encrypted white-list may be restricted by a time to live (TTL). In one embodiment, the method uses a TTL timer to determine the TTL of a decrypted white-list stored in a cache. The TTL timer is initialized instep 614. In one embodiment, the TTL timer is configured by a server and downloaded by the executing device. For example, the TTL timers of multiple executing devices may be controlled by a central device separate from the executing device. - In one embodiment, the method uses a polling timer to determine an interval by which to request, poll, scan, and/or survey identifiers of application control devices that are available to the executing device. In one embodiment, the duration of the polling timer is configured at the server and downloaded to the executing device. After the polling timer is initialized with an initial duration in
step 616, the method includes checking if it is time to poll for the identifier of the application control device instep 618. If it is not time to poll for the identifier of the application control device,step 618 is repeated until it is time to poll for the identifier of the application control device. If it is time to poll for the identifier of the application control device, the executing device may collect and/or receive at least one identifier of at least one application control device instep 620. For example, when it is time to poll for the identifier of the application control device, the executing device may check for the presence of the correct identifier to ensure that an authorized user is still near. For example, if the application control device is a mobile phone of an authorized user, the executing device will check to see if it has received the identifier of the mobile phone (e.g., an identifier of the mobile phone that is part of a Bluetooth network). If the identifier of the mobile phone is received, the white-list remains decrypted. In another example, if the application control device is an authorized user's ID badge, the executing device will transmit a signal to trigger, induce, and/or provoke transmission of the identifier of the authorized user's ID badge. If the identifier of the authorized user's ID badge is received, the white-list will remain decrypted. - In one embodiment, one identifier of one application control device is collected in
step 620. In some embodiments, at least two identifiers of at least two application control devices are collected, or at least three identifiers of at least three application control devices are collected, or at least four identifiers of at least four application control devices are collected, or at least five identifiers of at least five application control devices are collected. - After at least one identifier is collected in
step 620, the encrypted white-list is attempted to be decrypted using the at least one identifier collected and the decryption results are stored into cache. In one embodiment, the decryption results are filtered, checked and/or analyzed to confirm that only correct decryptions are stored. For example, encrypted white-lists that yield improper or non-functioning results (e.g., decrypted white-lists) after decryption may not be stored. In another embodiment, all decryption results from collected identifiers and encrypted white-lists are stored (e.g., including results from attempted decryptions using an incorrect application control device identifier). For example, a cache may store incorrect results that, when the cached results are reviewed in response to a request to execute an executable (e.g., in an attempt to run the executing device in white-list-only mode), the executing device will not allow the executable to execute. In one embodiment, if the correct identifier is not collected instep 620, then the encrypted white-list is not decrypted. As described further herein, the results of the decryption may be checked to see if the decryption succeeded (e.g., in a usable decrypted white-list). - In one embodiment, if a correct identifier is collected, the TTL timer is
step 614 is reset to its initial value. In one embodiment, if a correct identifier is collected, the polling timer is reset to its initial value. In one embodiment, the TTL timer is periodically checked to see if the timer has expired. If the TTL timer has expired, the decrypted white-list may be deleted (e.g., from a cache Mere white-lists are checked). -
FIG. 5 is a schematic view of one embodiment of a system useful for handling white-lists in accordance with the present disclosure. In one embodiment, theidentifier 310 of theapplication control device 300 may be transmitted to the executingdevice 200. For example, if theapplication control device 300 is a wireless LAN transmitter and the executingdevice 200 is a laptop, the wireless LAN may include an SSID received by the laptop. In one embodiment, a transmitter of the wireless LAN (e.g., wireless access point) may transmit an SSID in the range of about from 50 meters to about 100 meters. For example, if the laptop is 70 meters from the wireless LAN, the laptop may receive the SSID. In another example, if the laptop is 130 meters from the wireless LAN, the laptop may not receive the SSID. - In one embodiment, the executing
device 200 may poll theapplication control device 300 for theidentifier 310. In one embodiment, the executingdevice 200 may poll theapplication control device 300, at the polling time, for theidentifier 310 at least once a second. In some embodiments, the executingdevice 200 may poll theapplication control device 300 for theidentifier 310 at least once every five seconds, or at least once every 10 seconds, or at least once every minute, or at least once every 10 minutes, or at least once every hour. For example, if theapplication control device 300 is a Bluetooth device and the executingdevice 200 is a mobile smartphone, the smartphone may poll the Bluetooth device for theidentifier 310 at least once every minute. - In one embodiment, the encrypted white-
list 240 may be partitioned. In one embodiment, the encrypted white-list 240 has at least two partitions. For example, a first partition of the encrypted white-list 240 may haveexecutable programs 260 with a minimal level of security requirement such as an operating system or applications related thereto. In one embodiment, the first partition may be decrypted using a first key that is available as an identifier of a wireless LAN transmitter (e.g., a wireless access point) located in a building. A second partition of the encrypted white-list 240 may haveexecutable programs 260 with a higher-level of security, such as a word processing application (e.g., Microsoft Office tools), or a company's VPN (Virtual Private Network) access, to name a few. In one embodiment, theidentifier 310 may be used to decrypt one partition of the encrypted white-list 240. For example, if theidentifier 310 is used to encrypt and decrypt the first partition of the encrypted white-list 240, operating system applications may be executed, but Microsoft Office tools and a companies VPN access may not be executed and/or accessed. In another example, the first partition of the encrypted white-list 240 is not encrypted, thereby allowing the operating system to boot in the executingdevice 200 regardless of whether there is anidentifier 310 received at the executingdevice 200. In another example, if theidentifier 310 is used to encrypt and decrypt the second partition of the encrypted white-list 240, but there is no identifier of the first partition of the encrypted white-list 240, then operating system applications may not be executed resulting in the executingdevice 200 denying access to the device entirely. In a multiple partitioned white-list, each partition may reference the type ofapplication control device 300 used to encrypt the partition. - In one embodiment, operating system applications may be referenced in an un-encrypted white-list, e.g., the
identifier 310 would not be required to start the operation system applications. In one embodiment, more than one white-list 240 may be utilized. For example, a first white-list may contain a list of operating system applications available to anyone with access to the executingdevice 200, a second white-list may contain Microsoft Office tools available to all employees of a company, and a third white-list may contain applications available only to managers of the company. In this example, a first identifier may be required to access the Microsoft Office tools and a second identifier may be required to access the applications available only to managers. This may apply to a partitioned white-list as well. - In one embodiment, the encrypted white-
list 240 may be encrypted by all or part of acomposite identifier 450, composed of a combination of theidentifier 310 of theapplication control device 300 and anidentifier 410 of a secondapplication control device 400. For example, in one embodiment, acomposite identifier 450 may be used to encrypt and decrypt the white-list 230. For example, both theidentifier 310 and theidentifier 410 may be received at the executingdevice 200 from the first and secondapplication control devices composite identifier 450 for use in decrypting an encrypted white-list. In one embodiment, thecomposite identifier 450 may allow execution and/or access to all theexecutable programs 260 referenced in the encrypted white-list 240. In one embodiment, thecomposite identifier 450 may allow execution and/or access to only some of theexecutable programs 260 referenced in the encrypted white-list 240. For example, thecomposite identifier 450 may serve to decrypt certain partitions of the encrypted white-list 240, but not others. - In one embodiment, the executing
device 200 may be required to be in a particular location before the encrypted white-list 240 may be decrypted. In one embodiment, theapplication control device 300 may be a GPS device in communication with a plurality of GPS satellites, and theidentifier 310 may be GPS information received from the GPS device. In one embodiment, theidentifier 310 received may be longitude and latitude data. (e.g., a location, a range of locations) indicating where the executingdevice 200 is permitted to be while it is executing certain executables on a partition of the encrypted white-list 240 or an individual encrypted white-list 240. In another embodiment, theapplication control device 300 may be a mobile phone and theidentifier 310 may be location information of the mobile phone, such as information related to a cellular tower used by the mobile phone. In one embodiment, a secondapplication control device 400 may be required to decrypt the encrypted white-list 240. For example, if the executingdevice 200 is located in the proper location after receiving the identifier 310 (e.g., location information), the executingdevice 200 may additionally require theidentifier 410 of the secondapplication control device 400 to decrypt the encrypted white-list or a partition thereof. - As demonstrated in the above examples, the present disclosure may mitigate theft of data because even if the executing
device 200 is stolen, without the presence of at least one of theapplication control devices 300/400 theexecutable programs 260 referenced in the encrypted white-list 240 will not execute, and in some cases, the executingdevice 200 may not boot at all. - The
composite identifier 450 may include multiple identifiers of multiple application control devices in order to encrypt and decrypt the white-list 230 and for the executingdevice 200 to allow execution of authorized executables. In one embodiment, thecomposite identifier 450 may include at least 3 identifiers of at least 3 application control devices. In some embodiments, thecomposite identifier 450 may include at least 4 identifiers of at least 4 application control devices, or at least 5, or at least 6. More identifiers and application control devices may be used. -
FIG. 6 is a flow chart of one embodiment of methods of managing access to an executing device including generation of an encrypted white-list. For example, one or more white-list(s) may need to have their encryption modified (e.g., re-encrypted) or may need to be recovered, repaired, and/or replaced if the executing device loses functionality in one or more white-lists (e.g., device malfunctions, device experiences memory error). In one embodiment, the method includes requesting a reduction (e.g., a “step down”) of the encryption of the encrypted white-list instep 710. For example, an administrator may request that a white-list or a partition thereof be decrypted and re-encrypted with a new identifier (e.g., an identifier of another application control device). As another example, an administrator may request that a first encrypted white-list be replaced with a second encrypted white-list. In one embodiment, an entire white-list on an executing device or a partition of the encrypted white-list may be re-encrypted, recovered, repaired, and/or replaced. In one embodiment, a white-list or partition of a white-list may be replaced with another white-list with a lower level of encryption, or with no encryption at all. For example, one partition of the encrypted white-list may be “stepped down” to a second partition of the encrypted white-list with a lower level of encryption. In one embodiment, the white-list may be “stepped down” to a lower level of encryption through receiving the request instep 712 and attempt to decrypt the white-list instep 714. Instep 718, the encrypted white-list may be re-created via encrypting the white-list. For example, the white-list may be re-encrypted with a new identifier. As described further herein, the white-list may be encrypted using a new identifier provided by a server. Instep 716, the white-list may be left decrypted. For example, an administrator may determine that a white-list or a partition thereof should not be encrypted. After the white-list is encrypted instep 718 or if the white-list is determined instep 716 not to be re-encrypted, the new white-list with modified encryption (or lack of encryption) is provided instep 720. For example, a server may receive the white-list for distribution, such as to an executing device. - While various embodiments of the new technology described herein have been described in detail, it is apparent that modifications and adaptations of those embodiments will occur to those skilled in the art. However, it is to be expressly understood that such modifications and adaptations are within the spirit and scope of the presently disclosed technology.
Claims (19)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/226,294 US20140208107A1 (en) | 2010-10-11 | 2014-03-26 | Systems and methods for implementing application control security |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US39202210P | 2010-10-11 | 2010-10-11 | |
US13/269,040 US8707444B2 (en) | 2010-10-11 | 2011-10-07 | Systems and methods for implementing application control security |
US14/226,294 US20140208107A1 (en) | 2010-10-11 | 2014-03-26 | Systems and methods for implementing application control security |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/269,040 Continuation US8707444B2 (en) | 2010-10-11 | 2011-10-07 | Systems and methods for implementing application control security |
Publications (1)
Publication Number | Publication Date |
---|---|
US20140208107A1 true US20140208107A1 (en) | 2014-07-24 |
Family
ID=44946963
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/269,040 Active US8707444B2 (en) | 2010-10-11 | 2011-10-07 | Systems and methods for implementing application control security |
US14/226,294 Abandoned US20140208107A1 (en) | 2010-10-11 | 2014-03-26 | Systems and methods for implementing application control security |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/269,040 Active US8707444B2 (en) | 2010-10-11 | 2011-10-07 | Systems and methods for implementing application control security |
Country Status (2)
Country | Link |
---|---|
US (2) | US8707444B2 (en) |
EP (1) | EP2439673A3 (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9430216B2 (en) | 2014-05-11 | 2016-08-30 | Lumension Security, Inc. | Self-contained executable for predetermined software updating |
US20190065735A1 (en) * | 2017-08-22 | 2019-02-28 | Kabushiki Kaisha Toshiba | Information processing apparatus, information processing method, and computer program product |
US20210092097A1 (en) * | 2019-09-23 | 2021-03-25 | Fisher-Rosemount Systems, Inc. | Whitelisting for HART Communications in a Process Control System |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102842007B (en) | 2012-07-16 | 2015-03-11 | 腾讯科技(深圳)有限公司 | Access control method and system of mobile terminal application program |
KR102032247B1 (en) * | 2013-01-15 | 2019-10-15 | 삼성전자 주식회사 | Method and apparatus for operating near field communication function in a portable terminal |
JP5863689B2 (en) * | 2013-02-28 | 2016-02-17 | 京セラドキュメントソリューションズ株式会社 | Shared library with unauthorized use prevention function |
KR101416717B1 (en) * | 2013-03-28 | 2014-07-09 | (주)엠더블유스토리 | System for preventing malicious intrusion based on smart device and method thereof |
US9727351B2 (en) * | 2013-04-08 | 2017-08-08 | Xiaomi Inc. | Method and device for setting status of application |
US9703946B2 (en) * | 2014-03-31 | 2017-07-11 | Stmicroelectronics Asia Pacific Pte Ltd | Secure pairing method, circuit and system for an intelligent input device and an electronic device |
US9225733B1 (en) | 2014-08-25 | 2015-12-29 | Trend Micro Incorporated | Preventing computer worms from attacking a private computer network through a virtual private network connection |
US20230214479A1 (en) * | 2022-01-04 | 2023-07-06 | Saudi Arabian Oil Company | Method and system for detecting and preventing unauthorized access to a computer |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060150256A1 (en) * | 2004-12-03 | 2006-07-06 | Whitecell Software Inc. A Delaware Corporation | Secure system for allowing the execution of authorized computer program code |
US20070143827A1 (en) * | 2005-12-21 | 2007-06-21 | Fiberlink | Methods and systems for intelligently controlling access to computing resources |
US20080107274A1 (en) * | 2006-06-21 | 2008-05-08 | Rf Code, Inc. | Location-based security, privacy, assess control and monitoring system |
US20090241170A1 (en) * | 2008-03-19 | 2009-09-24 | Applied Identity | Access, priority and bandwidth management based on application identity |
US20100082987A1 (en) * | 2008-09-30 | 2010-04-01 | Microsoft Corporation | Transparent trust validation of an unknown platform |
US8015606B1 (en) * | 2005-07-14 | 2011-09-06 | Ironkey, Inc. | Storage device with website trust indication |
US20110299679A1 (en) * | 2010-06-04 | 2011-12-08 | Takahiro Yamaguchi | Controller, control method, computer program, recording medium for computer program, recording apparatus, and manufacturing method for recording apparatus |
US20120036220A1 (en) * | 2008-12-19 | 2012-02-09 | Openpeak Inc. | Systems for accepting and approving applications and methods of operation of same |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CA2423175A1 (en) | 2000-09-22 | 2002-03-28 | Patchlink.Com Corporation | Non-invasive automatic offsite patch fingerprinting and updating system and method |
US7278158B2 (en) | 2001-03-16 | 2007-10-02 | Securewave S.A. | Method and system for shadowing accesses to removable medium storage devices |
US20030014667A1 (en) | 2001-07-16 | 2003-01-16 | Andrei Kolichtchak | Buffer overflow attack detection and suppression |
US7487495B2 (en) | 2004-04-19 | 2009-02-03 | Lumension Security, Inc. | Generic framework for runtime interception and execution control of interpreted languages |
EP2267625A3 (en) | 2004-04-19 | 2015-08-05 | Lumension Security S.A. | On-line centralized and local authorization of executable files |
US20090210267A1 (en) | 2008-02-18 | 2009-08-20 | Bryan David Fish | System and method for automatically mapping security controls to subjects |
-
2011
- 2011-10-06 EP EP11184220A patent/EP2439673A3/en not_active Withdrawn
- 2011-10-07 US US13/269,040 patent/US8707444B2/en active Active
-
2014
- 2014-03-26 US US14/226,294 patent/US20140208107A1/en not_active Abandoned
Patent Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060150256A1 (en) * | 2004-12-03 | 2006-07-06 | Whitecell Software Inc. A Delaware Corporation | Secure system for allowing the execution of authorized computer program code |
WO2006101549A2 (en) * | 2004-12-03 | 2006-09-28 | Whitecell Software, Inc. | Secure system for allowing the execution of authorized computer program code |
US8015606B1 (en) * | 2005-07-14 | 2011-09-06 | Ironkey, Inc. | Storage device with website trust indication |
US20070143827A1 (en) * | 2005-12-21 | 2007-06-21 | Fiberlink | Methods and systems for intelligently controlling access to computing resources |
US20080107274A1 (en) * | 2006-06-21 | 2008-05-08 | Rf Code, Inc. | Location-based security, privacy, assess control and monitoring system |
US20090241170A1 (en) * | 2008-03-19 | 2009-09-24 | Applied Identity | Access, priority and bandwidth management based on application identity |
US20100082987A1 (en) * | 2008-09-30 | 2010-04-01 | Microsoft Corporation | Transparent trust validation of an unknown platform |
US20120036220A1 (en) * | 2008-12-19 | 2012-02-09 | Openpeak Inc. | Systems for accepting and approving applications and methods of operation of same |
US20110299679A1 (en) * | 2010-06-04 | 2011-12-08 | Takahiro Yamaguchi | Controller, control method, computer program, recording medium for computer program, recording apparatus, and manufacturing method for recording apparatus |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9430216B2 (en) | 2014-05-11 | 2016-08-30 | Lumension Security, Inc. | Self-contained executable for predetermined software updating |
US20190065735A1 (en) * | 2017-08-22 | 2019-02-28 | Kabushiki Kaisha Toshiba | Information processing apparatus, information processing method, and computer program product |
US11281766B2 (en) * | 2017-08-22 | 2022-03-22 | Kabushiki Kaisha Toshiba | Information processing apparatus, information processing method, and computer program product |
US20210092097A1 (en) * | 2019-09-23 | 2021-03-25 | Fisher-Rosemount Systems, Inc. | Whitelisting for HART Communications in a Process Control System |
Also Published As
Publication number | Publication date |
---|---|
EP2439673A3 (en) | 2012-05-30 |
EP2439673A2 (en) | 2012-04-11 |
US8707444B2 (en) | 2014-04-22 |
US20120090033A1 (en) | 2012-04-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8707444B2 (en) | Systems and methods for implementing application control security | |
US10924271B2 (en) | Vehicle access systems and methods | |
RU2620998C2 (en) | Method and authentication device for unlocking administrative rights | |
CN1953375B (en) | Account management in a system and method for providing code signing services | |
AU2015287628B2 (en) | Networked access control system | |
CA2954758C (en) | Electronic credential management system | |
EP2731040B1 (en) | Computer system for storing and retrieval of encrypted data items, client computer, computer program product and computer-implemented method | |
CN101258505B (en) | Secure software updates | |
EP2383675B1 (en) | Thin client-server system, thin client terminal, data management method, and computer readable recording medium | |
CN106375091B (en) | Establishing a communication link to a user equipment via an access control device | |
US9146881B2 (en) | Mobile data vault | |
US20110238980A1 (en) | System and methods for remote maintenance in an electronic network with multiple clients | |
CN102609662A (en) | Tamper proof location services | |
CN102624699A (en) | Method and system for protecting data | |
KR20150024388A (en) | Security mode for mobile communications devices | |
CA2538850A1 (en) | Record carrier, system, method and program for conditional access to data stored on the record carrier | |
EP2405376A1 (en) | Utilization of a microcode interpreter built in to a processor | |
CN100476841C (en) | Method and system for centrally managing code to hard disk of enterprise | |
JP2007179357A (en) | Method for installing computer program | |
CN101867485B (en) | USB interface authentication and security control method | |
CN117896080A (en) | Digital key management system, management server, vehicle, and digital key management method | |
CN114513775A (en) | Method and system for controlling BLE equipment based on server side authorization terminal | |
KR100899140B1 (en) | Method and device for re-dispatching specifically coded access objects from a server to a mobile terminal device | |
CN113439292A (en) | System and method for managing trusted applications in a computer chip module |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: LUMENSION SECURITY, INC., ARIZONA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KELLY, CIARAN;MOLLOY, IARLA;REEL/FRAME:032973/0605 Effective date: 20111110 |
|
AS | Assignment |
Owner name: CONSORTIUM FINANCE, LLC, CALIFORNIA Free format text: FIRST AMENDMENT TO PATENT SECURITY AGREEMENT;ASSIGNORS:NETMOTION WIRELESS HOLDINGS, INC.;NETMOTION WIRELESS, INC.;LUMENSION SECURITY, INC.;REEL/FRAME:035061/0615 Effective date: 20150219 |
|
AS | Assignment |
Owner name: WELLS FARGO BANK, NATIONAL ASSOCIATION, CALIFORNIA Free format text: FIRST AMENDMENT TO PATENT SECURITY AGREEMENT;ASSIGNOR:LUMENSION SECURITY, INC.;REEL/FRAME:035111/0448 Effective date: 20150219 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: NETMOTION WIRELESS, INC., WASHINGTON Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CONSORTIUM FINANCE, LLC;REEL/FRAME:040479/0001 Effective date: 20161007 Owner name: LUMENSION SECURITY, INC., WASHINGTON Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CONSORTIUM FINANCE, LLC;REEL/FRAME:040479/0001 Effective date: 20161007 Owner name: NETMOTION WIRELESS HOLDINGS, INC., WASHINGTON Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CONSORTIUM FINANCE, LLC;REEL/FRAME:040479/0001 Effective date: 20161007 |
|
AS | Assignment |
Owner name: HEAT SOFTWARE USA INC., AS SUCCESSOR IN INTEREST T Free format text: RELEASE OF SECURITY INTERESTS IN PATENTS AT REEL/FRAME NO. 35111/0448;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION;REEL/FRAME:041052/0802 Effective date: 20170120 |