EP3149882A1 - Cadriciel mobile sécurisé à vérification d'intégrité de système d'exploitation - Google Patents

Cadriciel mobile sécurisé à vérification d'intégrité de système d'exploitation

Info

Publication number
EP3149882A1
EP3149882A1 EP15803008.0A EP15803008A EP3149882A1 EP 3149882 A1 EP3149882 A1 EP 3149882A1 EP 15803008 A EP15803008 A EP 15803008A EP 3149882 A1 EP3149882 A1 EP 3149882A1
Authority
EP
European Patent Office
Prior art keywords
key
remote device
operating system
service
enterprise
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.)
Withdrawn
Application number
EP15803008.0A
Other languages
German (de)
English (en)
Other versions
EP3149882A4 (fr
Inventor
Daniel FALTYN
Andrew J.R. Smith
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sncr LLC
SNCR LLC
Original Assignee
Sncr LLC
SNCR LLC
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority claimed from US14/293,765 external-priority patent/US20140281539A1/en
Application filed by Sncr LLC, SNCR LLC filed Critical Sncr LLC
Publication of EP3149882A1 publication Critical patent/EP3149882A1/fr
Publication of EP3149882A4 publication Critical patent/EP3149882A4/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • 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/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0863—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving passwords or one-time passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • 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

Definitions

  • Various embodiments of the present invention generally relate to mobile devices. More specifically, some embodiments of the present invention relate to a secure mobile framework for securely connecting applications running on mobile devices to services within an enterprise.
  • MDM mobile device management
  • OS software and operating system
  • MDM polices can be cumbersome to the user who may also be using the device in a personal capacity.
  • an MDM policy may require the mobile device to auto lock and prompt the user to provide a password with a particular set of characteristics before the mobile device is unlocked. The user may find these restrictions annoying.
  • Systems and methods are described for a secure mobile framework capable of securely connecting applications running on mobile devices to services (e.g., an e-mail service, a trading service, or a reservation service) within an enterprise.
  • an authentication request from a remote device to access a service provided by an enterprise can be received at a gateway associated with the enterprise.
  • the request can originate from an enterprise- managed application running on the remote device.
  • a framework authentication token and security policy e.g., password structure, password duration, access controls for an application and/or secure container of data, etc.
  • the security policy can be based on the service provided by the enterprise that the remote device is requesting to access.
  • the framework authentication token and the security policy can then be transmitted to the remote device which ensures compliance with the security policy before generating a connection request to connect to the service within the enterprise.
  • the connection request can be based on the framework authentication token and the security policy.
  • a service authenticator determines if the application running on the remote device is authorized to access the service. Some embodiments monitor interactions between the enterprise-managed application and the service. Upon detecting a violation of one or more fraud policies at the mobile device and/or gateway, an elevated authentication request can be generated.
  • a request can be received from an initiating device to establish a service connection between an enterprise-managed application running on the initiating device and an enterprise service.
  • the request includes authentication credentials associated with an end-user.
  • a framework authentication token can be generated and transmitted to the initiating device, wherein upon receipt the initiating device initiates a service connection request based on the authentication token.
  • a secure connection can be created between the enterprise service and the initiating device upon successful validation (e.g., authorization and authentication) of the service connection request. Any data transmitted to the initiating device using the stored connection can be stored within a secure container that is only accessible by the enterprise-managed application.
  • the authentication framework may validate, or at least require that, the operating system integrity and/or the enterprise-managed application integrity be determined if a connection can be established between the enterprise-managed application and the service.
  • One of the overall objectives of evaluating the operating system integrity is to evaluate the integrity of execution environment by testing various aspects of the sandbox.
  • the sandbox is a set of restrictive policies and mechanisms which the operating system uses to enforce a particular scope of operation on the application.
  • various embodiments have the application test known limits. If these known limits can be passed, then the device appears to have a compromised operating system integrity (e.g., jail broken or rooted).
  • the hacker may suspect there are protections in the code.
  • some embodiments are designed to force or lead the hacker down an avenue of analysis and patching that requires all checks to be discovered and removed.
  • Various embodiments also add safeguards and countermeasures to make the cost of getting the analysis wrong and expensive by destroying usable information as quickly as possible.
  • the code path can be changed to yield different results or ultimately deny access to the enterprise.
  • Some embodiments not only check the OS integrity, but also check the executing application's integrity. This is certainly one form of defense against the broken operating system which looks intact however allows a re-crafted and malicious binary to operate. There are some inherent limitations to guaranteeing operating system integrity by the very nature of where the checks are being performed. If a compromised (e.g., jail broken or rooted) operating system looks perfectly intact from the applications perspective, then the application will operate under that assumption. Alternatively, if the hacker completely analyzes the binary and removes all integrity checks perfectly the first time such that it executes as if there were no checks engineered into it then equally it would act as normal. In both of these situations, additional defenses may be found in a DMZ and anomaly detection system which monitor the use of the applications activity to differentiate between legitimate and illegitimate users.
  • Embodiments of the present invention also include computer-readable storage media containing sets of instructions to cause one or more processors to perform the methods, variations of the methods, and other operations described herein.
  • a system can include a gateway, an authenticator, a token generator, a communications module, a discovery service, and/or a fraud detection module.
  • the gateway can be configured to provide remote devices access to services of an enterprise.
  • the gateway can include multiple levels, each of which provides isolated authentication protocols and activity logging.
  • the remote devices can have stored thereon one or more applications managed by the enterprise.
  • the authenticator can be configured to determine if a user is authorized to access the enterprise and to construct policies regarding the management of the one or more applications.
  • the token generator can be configured to generate one or more tokens (e.g., authentication token, a user binding token, and/or a framework authentication token) for creating secure connections between one or more applications managed by the enterprise and servers.
  • the tokens can be based on various identifiers such as, but not limited to the following: user identifiers, device identifiers, device type identifiers, application family identifiers, etc. Some tokens may include a binding of other tokens.
  • a framework authentication token can be based on an enterprise authentication token, a user binding token, and/or a framework authentication token expiration date.
  • one or more of the tokens may be cryptographically secured (e.g., digitally signed) that allow for the system to detect if the tokens have been tampered with or altered.
  • the communications module can be configured to communicate the policies to the remote devices.
  • the discovery service can be configured to determine which of the services of the enterprise to connect with the one or more applications.
  • the anomaly detector can be configured to monitor activity between the remote devices and the servers and generate an indicator of anomalies in activity. For example, the anomaly detector may monitor the IP velocity of the user, failed log-in attempts, etc.
  • FIG. 1 illustrates an example of a network-based environment in which some embodiments of the present invention may be utilized
  • FIG. 2 is a flowchart with a set of exemplary operations for creating a binding between an enterprise-managed application and an enterprise service in accordance with one or more embodiments of the present invention
  • FIG. 3 illustrates a set of components within a user device according to one or more embodiments of the present invention
  • Fig. 4 illustrates a general architecture for a secure framework which can be used in accordance with various embodiments of the present invention
  • FIG. 5 is a flowchart illustrating a set of exemplary operations for authorizing an enterprise-managed application in accordance with some embodiments of the present invention
  • FIG. 6 is a flowchart illustrating a set of exemplary operations for creating a secure channel between an enterprise service and an enterprise-managed application running on a remote device in accordance with one or more embodiments of the present invention
  • Fig. 7 is an example of an application built on a secure mobile framework which can be used with various embodiments of the present invention.
  • FIG. 8 illustrates a remote device accessing a service within an enterprise in accordance with some embodiments of the present invention
  • FIG. 9 is a sequence diagram illustrating an initial authentication flow between a device application and an enterprise in accordance with one or more embodiments of the present invention.
  • Fig. 10 is a sequence diagram illustrating a continuous authentication flow between a device application and an enterprise in accordance with various embodiments of the present invention
  • Fig. 1 1 illustrates a multi-stage key generation process based on multiple OS integrity checks in accordance with one or more embodiments of the present invention
  • Fig. 12 illustrates an example of an ephemeral key generation in accordance with some embodiments of the present invention
  • Fig. 13 illustrates an application integrity check in accordance with various embodiments of the present invention.
  • Fig. 14 illustrates an example of a computer system with which some embodiments of the present invention may be utilized.
  • Various embodiments of the present invention relate generally to a secure mobile framework capable of securely connecting applications running on mobile devices to services within an enterprise.
  • Some examples of services provided by an enterprise include, but are not limited to, an e-mail service, a trading service, a payment processing service, a customer relationship management service, an inventory system service, a business intelligence service, a healthcare service, a student information service, a reservation service, secure services, and/or other services containing sensitive information.
  • the secure mobile framework provides a collection of software libraries and service components which provide software developers the ability to build secure applications on non-enterprise mobile devices.
  • the secure mobile framework can be used in conjunction by enterprises that have firewalled content, services, and network from the public network through means of a DMZ-type architecture. As a result, much of the enterprise's existing authentication and authorization systems can be utilized. Client and server libraries can be utilized or extended to provide secure storage and communication in both the client and server applications.
  • the secure mobile framework can provide one or more of the following features to connect and utilize services within the enterprise: 1 ) mechanisms to store enterprise content on a device in a protected manner whereby the enterprise content can only be accessed by authorized users, possibly offline, and be managed through enterprise policy; 2) mechanisms to provide multiple authentications against the gateway (i.e., framework authentication) and against the enterprise services (i.e., enterprise authentication), provide secure connection to those enterprise services where authorized, and manage per service access through enterprise policy; 3) mechanism to manage and support connected applications and their dependent services; and 4) mechanisms to dynamically detect an undesirable or unsafe operating system environment and manage through a multi-step process (e.g., evaluating the policy, interrogation of the program, interrogation of the OS, and/or performing other checks in the client and/or server environments).
  • framework authentication i.e., framework authentication
  • enterprise services i.e., enterprise authentication
  • the gateway can generate one or more tokens which can be used for authentication.
  • an enterprise authentication token (EAT) can be generated representing a single or multi-factor credentials that can be used to authenticate with a given company as if single or multi factor credentials were presented, for a finite period of time.
  • a user binding token (UBT) can also be used in one or more embodiments.
  • the UBT can be an amalgamated, unique representation of a user (id), device (id), type of device, and app family.
  • a framework authentication token FAT can be used in various embodiments.
  • the FAT can be created by binding an EAT, UBT, and an expiration date used to authenticate with the framework.
  • One advantage of this construction of the FAT is that the details cannot be tampered with by an unauthorized party.
  • secure mobile framework client and server components can be used to detect the integrity of the operational environment for the client application. Given that the client application is executed within an unmanaged operating system environment, the client application may need to ascertain, as best it can, if the environment is considered to be unsafe. Common examples of unsafe operating system environments are devices on which the operating system restrictions that have been imposed by the OS manufacturer have been removed. This is commonly referred to as jailbreaking or rooting. In the case of Apple's iOS, for example, this process usually means removing various components of the code signing verification system and file access imposed by Seatbelt.
  • the operating system provides the security bedrock for many embodiments of the secure mobile framework by providing secure boot chain, signature enforced executables and sandboxed applications.
  • a broken operating system cannot be trusted as it is possible that the broken operating system could be running malicious code performing anything from data leakage to a platform for advance persistent threat attacks (APT).
  • API advance persistent threat attacks
  • embodiments may include a machine-readable medium having stored thereon instructions that may be used to program a computer (or other electronic devices) to perform a process.
  • the machine-readable medium may include, but is not limited to, floppy diskettes, optical disks, compact disc readonly memories (CD-ROMs), magneto-optical disks, ROMs, random access memories (RAMs), erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), application- specific integrated circuits (ASICs), magnetic or optical cards, flash memory, or other type of media / machine-readable medium suitable for storing electronic instructions.
  • CD-ROMs compact disc readonly memories
  • ROMs read-only memories
  • RAMs random access memories
  • EPROMs erasable programmable read-only memories
  • EEPROMs electrically erasable programmable read-only memories
  • ASICs application- specific integrated circuits
  • connection or coupled and related terms are used in an operational sense and are not necessarily limited to a direct physical connection or coupling.
  • two devices may be coupled directly, or via one or more intermediary media or devices.
  • devices e.g., mobile devices, server machines, etc.
  • connection or coupling exists in accordance with the aforementioned definition.
  • module refers broadly to a software, hardware, firmware, or service (or any combination thereof) component. Modules are typically functional components that can generate useful data or other output using specified input(s). A module may or may not be self-contained. An application program (also called an "application”) may include one or more modules, or a module can include one or more application programs.
  • Fig. 1 illustrates an example of a network-based environment 100 in which some embodiments of the present invention may be utilized.
  • various enterprise-managed applications 1 10A-1 10N can be running on user devices 120A-120N.
  • user devices 120A-120N may or may not be managed by the enterprise.
  • User devices 120A-120N can include enterprise-managed applications 1 10A-1 10N that can be used to access services and data within the enterprise.
  • User devices 120A-120N may use network 140 to submit and retrieve information from services within the enterprise.
  • User devices 120A-120N can interact with various enterprise services through an application programming interface (API) that runs on the native operating system of the device, such as IOS® or ANDROIDTM.
  • API application programming interface
  • Gateway 130 manages the access of enterprise-managed applications 1 10A-1 10N and user devices 120A-120N. Gateway 130 can be used to verify and establish a trust relationship between the enterprise-managed applications 1 10A- 1 1 ON and business-specific services provided by the enterprise. For example, in some embodiments, the data and requests initially submitted by enterprise-managed applications 1 10A-1 10N are transferred between the device and gateway 130 via network 140. Once gateway 130 is satisfied with the security of the device, then gateway 130 can open up a channel to some business-specific service within the application management platform 150 and enterprise services 160. Gateway 130 and services within the application management platform 150 can have multiple independent layers of security and checks.
  • User devices 120A-120N can be any computing device capable of receiving user input as well as transmitting and/or receiving data via the network 140.
  • user devices 120A-120N can be any device having computer functionality, such as a personal digital assistant (PDA), mobile telephone, smartphone, tablet, wearable types of mobile computers, body-mounted computers, or similar device.
  • PDA personal digital assistant
  • User devices 120A-120N can be configured to communicate via network 140, which may comprise any combination of local area and/or wide area networks, using wired and/or wireless communication systems.
  • network 140 uses standard communications technologies and/or protocols.
  • network 140 may include links using technologies such as Ethernet, 802.1 1 , worldwide interoperability for microwave access (WiMAX), 3G, 4G, CDMA, digital subscriber line (DSL), etc.
  • the networking protocols used within the various layers of network 140 may include multiprotocol label switching (MPLS), transmission control protocol/Internet protocol (TCP/IP), User Datagram Protocol (UDP), hypertext transport protocol (HTTP), hypertext transport protocol secure (HTTPs), simple mail transfer protocol (SMTP), file transfer protocol (FTP), secure file transfer protocol (SFTP), and/or other networking protocols.
  • Data exchanged over network 140 may be represented using technologies and/or formats including hypertext markup language (HTML) or extensible markup language (XML).
  • HTML hypertext markup language
  • XML extensible markup language
  • all or some links can be encrypted using conventional encryption technologies such as secure sockets layer (SSL), transport layer security (TLS), and Internet Protocol security (IPsec).
  • SSL secure sockets layer
  • TLS transport layer security
  • IPsec Internet Protocol security
  • Fig. 2 is a flowchart with a set of exemplary operations 200 for creating a binding between an enterprise-managed application and an enterprise service in accordance with one or more embodiments of the present invention.
  • installation operation 210 installs an enterprise controlled application on a remote device.
  • the application may be installed by an end-user of the device, an individual from the enterprise, or other source.
  • the application may be remotely installed or downloaded from an application store.
  • authentication operation 220 can prompt a user of the remote device to provide a set of credentials which can be authenticated against the framework.
  • a variety of security protocols and standards e.g., passwords, passcodes, time-based tokens, encrypted data, auto-lock, etc. may be used as part of the remote device and application security and authentication processes.
  • a variety of authentication and security checks can be performed at the enterprise during authentication operation 230.
  • an authorization request can be sent from the remote device (i.e., the client) to the gateway server.
  • the gateway server can determine a current policy which should be applied at the remote device and send policy information from the gateway server to the remote device. Then, the device characteristics can be checked and new container credentials can be acquired if necessary. If the gateway determines that the application should have access to one or more servers within the enterprise, creation operation 240 can be used to create a binding between the application and an enterprise service.
  • Various embodiments of the present invention provide systems and methods for checking the operating system integrity as part of authentication operation 230. These checks may be performed at the user device and/or at the enterprise. A broken operating system cannot be trusted as it is possible that the mobile device could be running malicious code performing anything from data leakage to a platform for advanced persistent threat attacks (APT). Because the process of jailbreaking an iOS device is relatively easy, it is quite possible that many of the devices will be broken for "legitimate" reasons. This still breaks the security model and opens doors for hackers. In fact, if steps are not taken to close some obvious holes, like changing the root password, the ability of a hacker to gain control of the device becomes extremely trivial. Various embodiments allow an enterprise gateway to use the operating integrity check in conjunction with other mobile application management techniques to determine if any violations are discovered. Access to enterprise services can be denied or immediately suspended if any violations are discovered.
  • API advanced persistent threat attacks
  • Fig. 3 illustrates a set of components of a user device 120 according to one or more embodiments of the present invention.
  • user device 120 can include memory 305, one or more application processors 310, baseband processors 315, power supply 320, operating system 325, application 330, secure container 335, validator 340, key generator 345, encryption/decryption module 350, access module 355, data removal module 360, information module 365, policy manager 370, communications module 375, and graphical user interface (GUI) generation module 380.
  • GUI graphical user interface
  • Other embodiments of the present invention may include some, all, or none of these modules and components along with other modules, applications, and/or components.
  • some embodiments may incorporate two or more of these modules and components into a single module and/or associate a portion of the functionality of one or more of these modules with a different module.
  • validator 340, key generator 345, and encryption/decryption module 350 can be combined into a single module for handling processing various encryption and decryption requests.
  • Memory 305 can be any device, mechanism, or populated data structure used for storing information.
  • memory 305 can encompass any type of, but is not limited to, volatile memory, nonvolatile memory, and dynamic memory.
  • memory 305 can be random access memory, memory storage devices, optical memory devices, media magnetic media, floppy disks, magnetic tapes, hard drives, SDRAM, RDRAM, DDR RAM, erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), compact disks, DVDs, and/or the like.
  • memory 305 may include one or more disk drives, flash drives, one or more databases, one or more tables, one or more files, local cache memories, processor cache memories, relational databases, flat databases, and/or the like.
  • memory 305 may include one or more disk drives, flash drives, one or more databases, one or more tables, one or more files, local cache memories, processor cache memories, relational databases, flat databases, and/or the like.
  • Memory 305 may be used to store instructions for running one or more applications or modules on application processor(s) 310.
  • memory 305 could be used in one or more embodiments to house all or some of the instructions needed to execute the functionality of operating system 325, application 330, secure container 335, validator 340, key generator 345, encryption/decryption module 350, access module 355, data removal module 360, information module 365, policy manager 370, communications module 375, and/or GUI generation module 380.
  • Application processor(s) (AP) 310 are the main processors of user device 120. Application processor(s) provide the processing power to support software applications, memory management, graphics processing, and multimedia.
  • AP 310 is communicably coupled with memory 305 and configured to run the operating system 325, the user interface, and the applications 330 stored on memory 305.
  • Baseband processor 315 is configured to perform signal processing and implement/manage real-time radio transmission operations of user device 120. These processors along with the other components may be powered by power supply 320 (e.g., a battery or other power source).
  • Operating system 325 provides a software package that is capable of managing the resources (e.g., hardware resource) of user device 120. Operating system 325 can also provide common services for software applications running on AP 310. In accordance with various embodiments of the present invention, operating system 325 may act as an intermediary between applications 330 and hardware components. Applications 330 may include can include enterprise- managed applications 1 10A-1 10N that can be used to access services and data within the enterprise.
  • User device 120 may also include secure container 335 that allows for information to be securely stored.
  • Secure container 335 may include one or more tokens or access keys that can be used to create a secure connection or validate a current state of user device 120.
  • secure container 335 can securely store information about an uncompromised operating system 325, information about an uncompromised application, and/or other information that may be sensitive.
  • secure container 335 may be encrypted/decrypted using information about operating system 325.
  • Secure container 335 may have multiple storage compartments that each contain different information.
  • the encryption/decryption process may use a multi-level or multi-stage key generation sequence.
  • validator 340 can be used to test the operating system integrity and/or the application integrity at multiple points.
  • Key generator 345 can then generate a key to access secure container 335 by performing a multi-level or multi-stage key generation sequence.
  • the key generation sequence may be based on the operating system integrity and/or the application integrity determined by validator 340.
  • encryption/decryption module 350 will generate a different key than the access key needed to access secure container 335.
  • the key generated by encryption/decryption module 350 can then be passed to access module 355.
  • Access module 355 is configured to allow access to the secure container within the memory of the remote device. If the key generated by encryption/decryption module 350 does not successfully decrypt the content, data removal module 360 can remove data stored in the secure container. In some embodiments, when validator 340 determines that the operating system integrity has been compromised, an immediate request to remove the data may be sent to data removal module 360 and/or a notification may be sent to the enterprise.
  • Other types of inputs may also be part of the key generation sequence.
  • information from a remote service or gateway may be used.
  • user-provided inputs e.g., passwords
  • Information module 365 can be used to collect this information.
  • various information about the current policy being enforced by policy manager 370 may also be used as part of the key generation sequence.
  • Communications module 375 may be configured to manage and translate any requests or messages between components of user device 120, graphical user interface screens, remote service, networks, and/or any other component into a format required by the destination component and/or system. Similarly, communications module 375 may be used to communicate between systems and/or modules that use different communication protocols, data formats, or messaging routines. According to some embodiments, system components can communicate through messaging methods including extensible markup language (XML), proprietary message formats, and/or others.
  • XML extensible markup language
  • GUI generation module 380 can generate one or more GUI screens that allow for interaction with user device 120.
  • GUI generation module 380 generates a graphical user interface allowing a user of the mobile device to set preferences, present reports, set device constraints, and/or otherwise receive or convey information to the user.
  • Fig. 4 illustrates a general architecture 400 for a secure mobile framework in accordance with various embodiments of the present invention.
  • the secure mobile framework components can be used to manage and protect enterprise content stored on mobile device 405.
  • mobile device 405 can include a secure storage 410, policy 420, and/or authentication store 425 for mobile application 415.
  • Mobile application 415 can have a virtual file system that sits under the application.
  • mobile application 415 can use or generate one or more ephemeral keys, which can have multiple constituent components. The ephemeral keys can be assigned to each partition of the virtual file system to encrypt every file with its own key.
  • Secure storage 410 can securely store enterprise data locally on mobile device 405.
  • Secure storage 410 can include a group of protected files managed as a single unit through policy 420.
  • enterprise content can be stored in encrypted files and accessed via random access methods.
  • various mechanisms can be used to set encryption block sizes on a per file basis and simultaneously maintain a sidecar index file used to aid with the synchronization content between client and service.
  • the protected files are held within a secure partition which uses a single encrypted master file to hold per file encryption keys and a translation between applications file names and obfuscate file names.
  • This secure file partition mechanism can be used to securitize not only application content directly but also used as a virtual file system for database servers hosted on the device, logging and telemetry data for customer support.
  • Policy 420 can be an application-specific (or application family) security policy set by the enterprise with which application 415 should comply.
  • An application family generally refers to a grouping of applications governed by a common policy that shares access to authorization and authentication information on a given device, for a given user.
  • Policy 420 can include the value of security variables used in authorization, authentication, and securitizing data on the device. For example, policy 420 can include password structure, how long the device can remain disconnected from the gateway, how many times the user can fail to enter in a correct password, and other security variables.
  • a further instance of a secure file partition is authentication store 425 which can contain authentication credentials (e.g., tokens and assertions), policy details, and a master encryption key used to encrypt all other secure file partitions' master files.
  • An authentication store master file store can be encrypted with an ephemeral key generated based on a user password or phrase.
  • authentication store 425 can be shared among multiple applications on the device to form a common store for enterprise access and sharing encrypted content.
  • application 415 can request access to one or more internal services within an enterprise running on servers 430 or virtual machines 435 after passing one or more device security checks.
  • the request from application 415 is first received at a perimeter gateway 440 where a first round of authentication is established before allowing application access to an intermediate layer 445.
  • Intermediate layer 445 authenticates the user and ensures that the policy being enforced by application 415 is up-to-date.
  • mobile device telemetry and configuration settings can be gathered, processed, analyzed, evaluated, and/or recorded within database 450. This information can be useful in creating (e.g., in real-time or in near real-time) various indicators of fraud or anomaly detection.
  • Intermediate layer 445 also allows application 415 to log into mobile application store 450.
  • proxy 455 can be used as an intermediary between application 415 and the servers 430.
  • Fig. 5 is a flowchart illustrating a set of exemplary operations 500 for authorizing an enterprise-managed application in accordance with some embodiments of the present invention.
  • a request from an enterprise-managed application can be received.
  • the request can identify a named service within the enterprise to which the application would like to connect.
  • Initiation operation 520 initiates a secure connection with a perimeter gateway.
  • the perimeter gateway can then ensure the policy operating on the device is up-to-date using policy verification operation 530 and that the user is still authorized to access enterprise services during user verification operation 540.
  • validation operation 550 validates the user's authentication credentials at the gateway. Enterprise credentials are then passed to the destination service during submission operation 560 where authentication and authorization take place during verification operation 570.
  • binding operation 580 creates a binding between the application and the named service.
  • Fig. 6 is a flowchart illustrating a set of exemplary operations 600 for creating a secure channel between an enterprise service and an enterprise- managed application running on a remote device in accordance with one or more embodiments of the present invention.
  • the user causes an enterprise-managed application running on a client device to launch during launch operation 610.
  • the application prompts the user for a set of container credentials.
  • the client device uses encryption operation 620 to encrypt the data and communication with a server gateway of the enterprise.
  • the enterprise-managed application can use a framework authentication token (FAT) to authenticate with the gateway, and an enterprise authentication token (EAT) to authenticate with a service.
  • FAT framework authentication token
  • EAT enterprise authentication token
  • Validation operation 630 determines (e.g., using a framework authentication system) the validity of the FAT.
  • a server authorizer can then construct one or more tokens for creating a secure connection to the enterprise service.
  • the server authorizer can create a User Binding Token (UBT) consisting of the user id, the application id, and the device id.
  • UBT User Binding Token
  • the FAT can be created by binding the UBT, EAT, and an expiration date.
  • the server authorizer may determine if the user is authorized to access the enterprise.
  • a secure mobile framework server can construct a policy based on the enterprise services the user can interact with.
  • the information in the policy can include the FAT expiration date, a type of enterprise authentication the user must perform when the FAT expires, and other policy information used to secure data on the mobile device.
  • the secure mobile framework server gateway can then respond to the mobile device with the FAT and the policy.
  • the calling client e.g., the mobile device
  • the application can then use generation operation 640 to generate a connection request upon verification of the policy enforcement.
  • creation operation 650 creates a secure channel between the enterprise-managed application and the enterprise service.
  • the application can ask the client secure mobile framework to connect to a particular enterprise service using some canonical name.
  • the framework can send the service name along with the UBT to the secure mobile framework server service authenticator over the same connection.
  • the service authenticator determines if the UBT is allowed to connect to that destination.
  • the secure mobile framework server service router can then map the canonical name to the real address of the service, and establish a connection.
  • the mobile application can now communicate freely over a secured channel once the enterprise authentication is successfully completed.
  • the application may ask the secure mobile framework to connect to a particular service using some canonical name.
  • the secure mobile framework can then send the service name along with the UBT and EAT to the secure mobile framework gateway.
  • this information can be used rather than the user entered enterprise credentials, at least until the FAT expires.
  • Fig. 7 is an example of an application built on a secure mobile framework which can be used with various embodiments of the present invention.
  • web browser 705 represents an implementation of a web browser capable of generating standard HTTP/S requests which may be wrapped in a custom protocol.
  • Web browser 705 can use communications API 710 to establish a connection to the gateway.
  • communications API 710 can be built on top of secure socket layer (SSL) to access secure factory API 715 for authenticating the user.
  • SSL secure socket layer
  • Typical web based applications require storage of data such as cookies shared with the server and historical URLs.
  • the web browser implementation illustrated in Fig. 7 uses storage API 720 and a secure file partition manager to encrypt data before utilizing the operating system underlying file system 725
  • Communications API 710 obtains the user's raw credentials or stored token (FAT) to establish a connection with an enterprise gateway using secure key store 730. For example, upon receiving the user's credentials, a secure key can be retrieved from secure key store 730. This key can be used to access a key chain after which subcomponents of the framework can be initialized.
  • System management 735 can receive, from the device/application, an identification of a current policy associated with the application. Using policy management 740 a determination can be made as to whether the policy associated with the application is up to date or needs to be updated. System management 735 can ensure that proper logging, virtual file system management, and page caching occur.
  • the gateway Upon successful authorization and authentication, the gateway requests policy and device information from communications API 710. Upon successful validation, the gateway can bind a connection to a web browser proxy service, capable of making HTTP/S calls within the enterprise. Web browser 705 can then transmit the wrapped HTTP/S requests through this channel.
  • Fig. 8 illustrates a remote device 805 accessing a server 810 within an enterprise in accordance with some embodiments of the present invention.
  • various embodiments of the present invention allow remote device 805 to access the enterprise through a multi-level authentication process.
  • a container authentication, a framework authentication, and an enterprise authentication should all be successfully completed in some embodiments.
  • Many traditional authentication systems would require that in order to use an application on a mobile device, a user typically enters a password to unlock the device and then supply a user name and password to authenticate against a remote service.
  • various embodiments of the present invention use multiple layers of security before allowing access to data on a device or connections to the remote services.
  • a request is sent to far mobile content gateway 820.
  • validation and authentication of the user and device can be confirmed.
  • an enterprise authentication service 830 e.g., RSA® or KerberosTM
  • the authentication process can include a username, a whitelist check, a policy check, and/or a destination check.
  • device telemetry and configurations can be monitored and transmitted to a second intermediate authentication layer. These allow for the user, device, and application to be authenticated.
  • a connection can be established with server 810.
  • Far mobile content gateway 820 can connect with mobile gateway services 835 for additional authentication services for access to servers within the enterprise.
  • a user can enter a password or other authentication credentials within application 815 that can be used to decrypt data stored locally on the device.
  • the user could present a FAT to a gateway process running on a remote environment.
  • the gateway process uses the FAT to authorize and authenticate the user and the device.
  • the user would present an EAT to the remote service.
  • the FAT and EAT can be stored locally on the device after preforming one or more pluggable forms of authentication (e.g., time codes+pin, biometrics, passwords, etc.).
  • the form of authentication can be rotated on a predefined schedule (e.g., periodic) or upon detection of one or more events.
  • the gateway can securely transmit the current authentication form to the mobile device which can be stored in the secure store.
  • Fig. 8 illustrates examples, such as HTTPS and TLS, of secure connections which can be used, other embodiments of the present invention can use different protocols for creating connections for messaging and transferring data between system components.
  • Fig. 9 is a sequence diagram illustrating an initial authentication flow between a device application and an enterprise in accordance with one or more embodiments of the present invention.
  • a user launches a device application.
  • An integrity detection process is used to determine if the expected OS integrity is present. For example, the integrity detection process can determine if the device is operating in an elevated unauthorized privilege (e.g., rooting or jailbreak) mode.
  • the device application requests a node identifier (e.g., a KerberosTM ID) and an authentication password, at which point the device identifier is obtained from the device.
  • An initial authentication request can then be submitted (e.g., using a secure connection) to the far content gateway.
  • the initial authentication request can include the authentication password, the device identifier, application family, the device type, and/or other information.
  • the far content gateway can then send an authentication request to an authentication service. Once authentication service authenticates the user, a UBT is registered by the mobile authorization service.
  • the mobile authorization service can authorize access, generate a UBT, and store the device identifier, the user name, application family, and the UBT.
  • the mobile authorization service signs the UBT and authentication token before returning a policy, a UBT, and a digital signature to the far content gateway.
  • the far content gateway then generates a FAT which is returned along with the policy, UBT and digital signature to the device application.
  • the policy may require the device application to request a new password for the secure container.
  • the FAT, UBT, and digital signature can then be stored in the secure container which can be locked with the password.
  • Fig. 10 is a sequence diagram illustrating a continuous authentication flow between a device application and an enterprise in accordance with various embodiments of the present invention.
  • a user launches a device application.
  • An operating system integrity check (e.g., a jail break detection process) can then be used to determine if the integrity of the operating system has been compromised. If the operating system integrity check determines that the operating system is not as expected, then the application will not be allowed to connect with the gateway. If integrity of the operating system is as expected, the device application retrieves the secure container password from the user and unlocks the secure container to retrieve the current policy. The device application checks the enforcement of the policy and connects to the far content gateway. The far content gateway checks the digital signature of the UBT and the authentication token. The far content gateway can also check a directory to determine the status of the username and if the UBT is on a whitelist.
  • an operating system integrity check e.g., a jail break detection process
  • the device application submits the canonical name of the enterprise service to which the device application wants to connect.
  • the far content gateway uses a destination service module to determine if the UBT is allowed to connect to that service. If the UBT is allowed to connect, the far content gateway binds a connection to the enterprise service, or a proxy to that service.
  • a success code is returned from the far content gateway to the device application along with the latest policy version.
  • the device application checks to see if the policy version just returned is greater than the policy retrieved from the secure container. If the policy version is greater, then the new policy is applied.
  • the FAT can then be retrieved from the secure container and the conversation with the far content gateway can be initiated.
  • Fig. 1 1 illustrates a multi-stage key generation process based on multiple OS integrity checks in accordance with one or more embodiments of the present invention.
  • assembly code routines can be inserted at strategic points in the secure mobile framework code to test for known breaks in OS integrity.
  • stopping operation 1 105 stops the debugger from attaching call. This forces binary modification to remove the key state from the keychain.
  • Asynchronous check 1 1 10 can pickup drive-by jailbreaks which happen after the application has been started.
  • Additional checks such as filesystem checks 1 1 15-1 135 can also be used to test the ability to look outside the application's filesystem sandbox.
  • the filesystem checks 1 1 15-1 135 can test either the ability to access or open files/directories which should be inaccessible. The result of each of these checks can be combined with an application nonce as part of the ephemeral key generation 1 140.
  • Actions can include visual actions, destructive actions, and/or an absence of a required operation.
  • the visual action can pop up a dialog which indicates to users that the device does not pass the sufficient integrity requirements and that this violates compliance policy.
  • the dialog may be shown for a period of time (e.g., for 5 seconds) before the application exits.
  • the exit may be conducted on a background thread and cannot be easily hooked out through an objective-c message override. This action informs the user that the phone does not pass the sufficient integrity requirements, something they may not be aware of, and that this violates policy.
  • Fig. 12 illustrates an example of an ephemeral key generation in accordance with some embodiments of the present invention.
  • an application nonce can be retrieved and a number of checks (Silent 2 & 3 as illustrated in Fig. 1 1 ) may be run as part of the normal container login process.
  • Each of the checks may be combined (e.g., XOR) with this nonce key in a particular way.
  • the generation of the ephemeral container key is dependent on the modified key and equally if the key is not modified then the key will be incorrectly generated and will fail to decrypt properly.
  • the check fails because the device has a compromised operating system, then the nonce will not be modified.
  • the original nonce key loaded and held in memory assuming the hacker knows that the nonce is a component to the key generation will be left untouched and is less likely to raise suspicion of being the problem.
  • Fig. 13 illustrates an application integrity check in accordance with various embodiments of the present invention.
  • the application integrity check in accordance with some embodiments, can be based on calculating a hash of some or all of the read only portions of the binary.
  • some embodiments can use an application nonce (e.g., a 20 byte nonce).
  • the nonce may be sent from the server and used to XOR with the calculated hash to produce a modified nonce.
  • the modified nonce can then be sent back to the server.
  • the modified nonce can be XOR'd with the original nonce to reveal the calculated hash. This calculated hash can be checked against a set of know pre-computed hash signatures.
  • the pre-computed has signature for an application can be calculated prior to application distribution. Based on this check, a determination can be made as to whether the binary has been modified in some way and is invalid. If there is a difference the application can be denied access to requested services and/or be given a modified policy which can be enacted on the device.
  • Embodiments of the present invention include various steps and operations, which have been described above. A variety of these steps and operations may be performed by hardware components which are part of a mobile device, server, or other computer system used within embodiments of the present invention. In some embodiments, these steps and operations may be embodied in machine-executable instructions, which may be used to cause a general-purpose or special-purpose processor programmed with the instructions to perform the steps. Alternatively, the steps may be performed by a combination of hardware, software, and/or firmware. As such, Fig. 14 illustrates some components which may be used as part of a computer system 1400 with which embodiments of the present invention may be utilized. As illustrated in Fig.
  • the computer system may include a bus 1410, at least one processor 1420, at least one communication port 1430, a main memory 1440, a removable storage media 1450, a read only memory 1460, and a mass storage 1470.
  • computer system 1400 may not include any local storage such as removable storage media 1450, mass storage 1470, and the like.
  • Processor(s) 1420 can be any known processor, such as, but not limited to, an Intel® Itanium® or Itanium 2® processor(s); AMD® Opteron® or Athlon MP® processor(s); ARM-based processors; or Motorola® lines of processors.
  • Communication port(s) 1430 can be any of an RS-232 port for use with a modem- based dialup connection, a 10/100 Ethernet port, or a Gigabit port using copper or fiber.
  • Communication port(s) 1430 may be chosen depending on a network such as a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system 1400 connects.
  • LAN Local Area Network
  • WAN Wide Area Network
  • Main memory 1440 can be Random Access Memory (RAM) or any other dynamic storage device(s) commonly known in the art.
  • Read only memory 1460 can be any static storage device(s) such as Programmable Read Only Memory (PROM) chips for storing static information such as instructions for processor 1420.
  • Mass storage 1470 can be used to store information and instructions. For example, hard disks such as the Adaptec® family of SCSI drives, an optical disc, an array of disks such as RAID, such as the Adaptec family of RAID drives, or any other mass storage devices may be used.
  • Bus 1410 communicatively couples processor(s) 1420 with the other memory, storage, and communication blocks.
  • Bus 1410 can be a PCI /PCI-X or SCSI based system bus depending on the storage devices used.
  • Removable storage media 1450 can be any kind of external hard-drives, floppy drives, IOMEGA® Zip Drives, Compact Disc - Read Only Memory (CD-ROM), Compact Disc - Re-Writable (CD-RW), and/or Digital Video Disk - Read Only Memory (DVD-ROM).
  • CD-ROM Compact Disc - Read Only Memory
  • CD-RW Compact Disc - Re-Writable
  • DVD-ROM Digital Video Disk - Read Only Memory
  • the present invention provides novel systems, methods and arrangements for a secure mobile framework for enterprise-managed applications. While detailed descriptions of one or more embodiments of the invention have been given above, various alternatives, modifications, and equivalents will be apparent to those skilled in the art without varying from the spirit of the invention. For example, while the embodiments described above refer to particular features, the scope of this invention also includes embodiments having different combinations of features and embodiments that do not include all of the described features.

Abstract

L'invention concerne des systèmes et des procédés pour un cadriciel mobile sécurisé pour connecter de manière sécurisée des applications s'exécutant sur des dispositifs mobiles à des services au sein d'une entreprise. Différents modes de réalisation mettent en œuvre des mécanismes consistant à sécuriser des données et une communication entre des dispositifs mobiles et des services de point d'extrémité faisant l'objet d'un accès à partir d'une passerelle d'autorisation de responsable, d'authentification, de détection d'anomalie, de détection de fraude et de gestion de politique. Certains modes de réalisation permettent l'intégration de mécanismes de sécurité côté serveur et client, et la liaison d'un utilisateur/d'une application/d'un dispositif à un service de point d'extrémité conjointement avec de multiples mécanismes de chiffrement. Par exemple, le cadriciel mobile sécurisé permet d'obtenir un contenant sécurisé sur le dispositif mobile, des fichiers sécurisés, une partition de système de fichier virtuel, une approche d'authentification à plusieurs niveaux, et un système de détection de fraude côté serveur. Dans certains modes de réalisation, l'approche d'authentification à plusieurs niveaux peut comprendre une vérification d'intégrité de système d'exploitation en tant que partie du cadriciel mobile sécurisé.
EP15803008.0A 2014-06-02 2015-06-02 Cadriciel mobile sécurisé à vérification d'intégrité de système d'exploitation Withdrawn EP3149882A4 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14/293,765 US20140281539A1 (en) 2012-03-30 2014-06-02 Secure Mobile Framework With Operating System Integrity Checking
PCT/US2015/033814 WO2015187716A1 (fr) 2014-06-02 2015-06-02 Cadriciel mobile sécurisé à vérification d'intégrité de système d'exploitation

Publications (2)

Publication Number Publication Date
EP3149882A1 true EP3149882A1 (fr) 2017-04-05
EP3149882A4 EP3149882A4 (fr) 2017-12-13

Family

ID=54767290

Family Applications (1)

Application Number Title Priority Date Filing Date
EP15803008.0A Withdrawn EP3149882A4 (fr) 2014-06-02 2015-06-02 Cadriciel mobile sécurisé à vérification d'intégrité de système d'exploitation

Country Status (2)

Country Link
EP (1) EP3149882A4 (fr)
WO (1) WO2015187716A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11538063B2 (en) 2018-09-12 2022-12-27 Samsung Electronics Co., Ltd. Online fraud prevention and detection based on distributed system

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109525624B (zh) 2017-09-20 2022-01-04 腾讯科技（深圳）有限公司 一种容器登录方法、装置及存储介质
CN109379190B (zh) * 2018-12-19 2021-09-21 世纪龙信息网络有限责任公司 密钥分配方法、装置、计算机设备及存储介质
US11599639B2 (en) 2019-08-15 2023-03-07 Blackberry Limited Methods and systems for identifying a compromised device through its unmanaged profile
US11645402B2 (en) 2019-08-15 2023-05-09 Blackberry Limited Methods and systems for identifying compromised devices from file tree structure
US11632377B2 (en) 2019-08-15 2023-04-18 Blackberry Limited Methods and systems to identify a compromised device through active testing
US11343258B2 (en) 2019-08-15 2022-05-24 Blackberry Limited Methods and systems for identifying a compromised device through its managed profile
US11822522B2 (en) * 2020-01-31 2023-11-21 EMC IP Holding Company LLC Intelligent filesystem for container images

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050138393A1 (en) * 2003-12-22 2005-06-23 Challener David C. Determining user security level using trusted hardware device
US8738932B2 (en) * 2009-01-16 2014-05-27 Teleputers, Llc System and method for processor-based security
KR101523420B1 (ko) * 2010-04-12 2015-05-27 인터디지탈 패튼 홀딩스, 인크 부팅 처리에서의 단계화 제어 해제
US9183415B2 (en) * 2011-12-01 2015-11-10 Microsoft Technology Licensing, Llc Regulating access using information regarding a host machine of a portable storage drive
WO2013149257A1 (fr) * 2012-03-30 2013-10-03 Goldman, Sachs & Co. Cadriciel mobile sécurisé
US8639619B1 (en) * 2012-07-13 2014-01-28 Scvngr, Inc. Secure payment method and system

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11538063B2 (en) 2018-09-12 2022-12-27 Samsung Electronics Co., Ltd. Online fraud prevention and detection based on distributed system

Also Published As

Publication number Publication date
EP3149882A4 (fr) 2017-12-13
WO2015187716A1 (fr) 2015-12-10

Similar Documents

Publication Publication Date Title
US20140281539A1 (en) Secure Mobile Framework With Operating System Integrity Checking
US9473533B2 (en) Secure mobile framework
US9860249B2 (en) System and method for secure proxy-based authentication
US20240064145A1 (en) Assigning identifiers to user sessions to manage security risk when monitoring access of a client device to services
US8266683B2 (en) Automated security privilege setting for remote system users
US8909930B2 (en) External reference monitor
WO2015187716A1 (fr) Cadriciel mobile sécurisé à vérification d'intégrité de système d'exploitation
US10785230B1 (en) Monitoring security of a client device to provide continuous conditional server access
US20120311322A1 (en) Secure Access to Data in a Device
EP3687139B1 (fr) Fourniture sécurisée et validation de jetons d'accès dans des environnements de réseau
US11032270B1 (en) Secure provisioning and validation of access tokens in network environments
US10812272B1 (en) Identifying computing processes on automation servers
US20210314339A1 (en) On-demand and proactive detection of application misconfiguration security threats
Alnahari et al. Authentication of IoT device and IoT server using security key
WO2019226510A1 (fr) Procédés et systèmes pour de multiples racines de confiance indépendantes
EP3817327A1 (fr) Surveillance de la sécurité d'un dispositif client pour fournir un accès conditionnel continu au serveur
US20080060060A1 (en) Automated Security privilege setting for remote system users
Svensk Mobile Device Security: Exploring the Possibilities and Limitations with Bring Your Own Device (BYOD)
Stötzner Design of an Android App2App redirect flow for the FAPI 2.0 standard
WO2008025137A1 (fr) Etablissement de privilege de securite pour utilisateurs de système éloignés
Dočár Bezpečnostní řešení pro cloudové technologie

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20161223

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
A4 Supplementary search report drawn up and despatched

Effective date: 20171113

RIC1 Information provided on ipc code assigned before grant

Ipc: G06F 21/62 20130101ALI20171107BHEP

Ipc: G06F 21/31 20130101ALN20171107BHEP

Ipc: H04L 9/08 20060101AFI20171107BHEP

Ipc: H04L 9/32 20060101ALI20171107BHEP

Ipc: G06F 21/57 20130101ALI20171107BHEP

Ipc: H04L 29/06 20060101ALN20171107BHEP

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20180612