U.S. patent application number 16/188660 was filed with the patent office on 2019-09-19 for passwordless and decentralized identity verification.
This patent application is currently assigned to CyberArk Software Ltd.. The applicant listed for this patent is CyberArk Software Ltd.. Invention is credited to Dima Barboi, Max Brin, Tal Kandel, Noam Zweig.
Application Number | 20190289012 16/188660 |
Document ID | / |
Family ID | 62027791 |
Filed Date | 2019-09-19 |
United States Patent
Application |
20190289012 |
Kind Code |
A1 |
Kandel; Tal ; et
al. |
September 19, 2019 |
PASSWORDLESS AND DECENTRALIZED IDENTITY VERIFICATION
Abstract
Techniques include receiving request for verification of an
identity, where the request includes no authentication information
associated with the identity; determining, based on a ledger shared
by a plurality of decentralized verification services, a
credibility score for the identity; where the ledger is developed
based on receiving information associated with a plurality of
different types of credibility-building actions taken by the
identity in an environment; determining whether the credibility
score for the identity can be validated by consensus by at least a
subset of the plurality of decentralized verification services; and
determining whether to verify the identity, where the determination
of whether to verify the identity is performed without using
authentication information associated with the identity.
Inventors: |
Kandel; Tal; (Pardes Hana
Karkur, IL) ; Brin; Max; (Rosh HaAyin, IL) ;
Barboi; Dima; (Tel Aviv, IL) ; Zweig; Noam;
(Raa'nana, IL) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
CyberArk Software Ltd. |
Petach-Tikva |
|
IL |
|
|
Assignee: |
CyberArk Software Ltd.
Petach-Tikva
IL
|
Family ID: |
62027791 |
Appl. No.: |
16/188660 |
Filed: |
November 13, 2018 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
15925006 |
Mar 19, 2018 |
10135835 |
|
|
16188660 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 63/0861 20130101;
H04L 63/08 20130101; H04L 67/10 20130101; H04L 63/102 20130101;
H04L 63/205 20130101; G06F 21/40 20130101; H04L 63/0876 20130101;
H04L 9/0637 20130101 |
International
Class: |
H04L 29/06 20060101
H04L029/06; H04L 29/08 20060101 H04L029/08; H04L 9/06 20060101
H04L009/06; G06F 21/40 20060101 G06F021/40 |
Claims
1. A non-transitory computer readable medium including instructions
that, when executed by at least one processor, cause the at least
one processor to perform operations for passwordless and
decentralized verification, the operations comprising: receiving,
at a first verification service, from among a plurality of
decentralized verification services, a request for verification of
an identity, wherein the request includes no authentication
information associated with the identity; determining, based on a
ledger maintained by the first verification service and shared by
the plurality of decentralized verification services, a credibility
score for the identity; wherein the ledger is developed based on
receiving information associated with a plurality of different
types of credibility-building actions taken by the identity in an
environment; determining whether the credibility score for the
identity can be validated by consensus by at least a subset of the
plurality of decentralized verification services; and determining,
based on whether the credibility score for the identity can be
validated by consensus, whether to verify the identity, wherein the
determination of whether to verify the identity is performed
without using authentication information associated with the
identity.
2. The non-transitory computer readable medium of claim 1, wherein
the request includes no authentication credentials associated with
the identity.
3. The non-transitory computer readable medium of claim 1, wherein
the operations further comprise allowing the identity to
communicate with an access-restricted resource if the identity is
verified.
4. The non-transitory computer readable medium of claim 1, wherein
the determining whether to verify the identity includes determining
whether to authenticate the identity.
5. The non-transitory computer readable medium of claim 1, wherein
the operations further comprise adjusting the credibility score for
the identity based on the determining whether to verify the
identity.
6. The non-transitory computer readable medium of claim 1, wherein
the first verification service is configured to determine what
information to store in the ledger and what information to store
external to the ledger.
7. The non-transitory computer readable medium of claim 1, wherein
the request for verification is made by the identity.
8. The non-transitory computer readable medium of claim 1, wherein
the request for verification is automatically generated by an
application associated with the identity.
9. The non-transitory computer readable medium of claim 1, wherein
the determining whether the credibility score for the identity can
be validated by consensus is based on the subset of the plurality
of decentralized verification services determining credibility
scores for the identity.
10. The non-transitory computer readable medium of claim 9, wherein
the determining whether the credibility score for the identity can
be validated by consensus is based on determining whether the
credibility score determined by the first verification service is
within a predetermined range of variance from the credibility
scores determined by the subset of the plurality of decentralized
verification services.
11. The non-transitory computer readable medium of claim 1, wherein
the determining the credibility score for the identity includes
calculating the credibility score based on the ledger maintained by
the first verification service.
12. The non-transitory computer readable medium of claim 1, wherein
the determining the credibility score for the identity includes
requesting that a resource external to the first verification
service calculate the credibility score.
13. The non-transitory computer readable medium of claim 1, wherein
the first verification service is verified to a blockchain network
that includes the plurality of decentralized verification
services.
14. The non-transitory computer readable medium of claim 13,
wherein the identity has a contract with the blockchain network
that includes the credibility score for the identity.
15. The non-transitory computer readable medium of claim 1, wherein
the operations further comprise enabling the identity to
communicate with an access-restricted resource upon verifying the
identity.
16. A computer-implemented method for passwordless and
decentralized verification, the method comprising: receiving, at a
first verification service, from among a plurality of decentralized
verification services, a request for verification of an identity,
wherein the request includes no authentication information
associated with the identity; determining, based on a ledger
maintained by the first verification service and shared by the
plurality of decentralized verification services, a credibility
score for the identity; wherein the ledger is developed based on
receiving information associated with a plurality of different
types of credibility-building actions taken by the identity in an
environment; determining whether the credibility score for the
identity can be validated by consensus by at least a subset of the
plurality of decentralized verification services; and determining,
based on whether the credibility score for the identity can be
validated by consensus, whether to verify the identity, wherein the
determination of whether to verify the identity is performed
without using authentication information associated with the
identity.
17. The computer-implemented method of claim 16, wherein the
credibility-building actions include a user associated with the
identity authenticating itself at a physical access point to a
building.
18. The computer-implemented method of claim 16, wherein the
credibility-building actions include a user associated with the
identity communicating electronically with other identities in the
environment.
19. The computer-implemented method of claim 16, wherein the
credibility-building actions include a user associated with the
identity creating electronic files in the environment.
20. The computer-implemented method of claim 16, wherein the
credibility-building actions include a user associated with the
identity modifying electronic files in the environment.
21.-30. (canceled)
Description
BACKGROUND
[0001] Many enterprises and service providers strive to improve
security and usability of services they provide over their
networks. Access control techniques such as single sign-on and the
like are popular because they may satisfy both security and
usability requirements established by enterprises and service
providers. For example, access control techniques such as single
sign-on and the like may permit a user to use one set of login
credentials (e.g., name and password) to access multiple related
yet independent systems. Further, many enterprises and service
providers store user names and passwords in a single repository,
which is vulnerable to credential harvesting attacks.
[0002] However, individual systems often have different credential
requirements and require users to update their passwords at
different intervals, resulting in users having to keep track of a
large number of different logon credentials for different systems.
There is thus a need for technological solutions for creating
passwordless and decentralized authentication to allow a system to
verify an identity without a password or other authentication
credential associated with the identity. There is further a need
for technological solutions allowing such decentralized
authentication where individual enterprises lack a sufficient
number of ledgers and thus need to coordinate with other
enterprises to perform decentralized authentication. In addition,
there is a need for technological solutions addressing what
information to store in, and what information to omit from, ledgers
used in decentralized authentication.
SUMMARY
[0003] The disclosed embodiments describe non-transitory computer
readable media and methods for providing passwordless and
decentralized authentication in a computer network environment. For
example, in an exemplary embodiment, there may be a non-transitory
computer readable medium including instructions that, when executed
by at least one processor, cause the at least one processor to
perform operations for passwordless and decentralized verification.
The operations may comprise: receiving, at a first verification
service, from among a plurality of decentralized verification
services, a request for verification of an identity, wherein the
request includes no authentication information associated with the
identity; determining, based on a ledger maintained by the first
verification service and shared by the plurality of decentralized
verification services, a credibility score for the identity;
wherein the ledger is developed based on receiving information
associated with a plurality of different types of
credibility-building actions taken by the identity in an
environment; determining whether the credibility score for the
identity can be validated by consensus by at least a subset of the
plurality of decentralized verification services; and determining,
based on whether the credibility score for the identity can be
validated by consensus, whether to verify the identity, wherein the
determination of whether to verify the identity is performed
without using authentication information associated with the
identity.
[0004] According to a disclosed embodiment, the request includes no
authentication credentials associated with the identity.
[0005] According to a disclosed embodiment, the operations further
include allowing the identity to communicate with an
access-restricted resource if the identity is verified.
[0006] According to a disclosed embodiment, the determining whether
to verify the identity includes determining whether to authenticate
the identity.
[0007] According to a disclosed embodiment, the operations further
include adjusting the credibility score for the identity based on
the determining whether to verify the identity.
[0008] According to a disclosed embodiment, the first verification
service is configured to determine what information to store in the
ledger and what information to store external to the ledger.
[0009] According to a disclosed embodiment, the request for
verification is made by the identity.
[0010] According to a disclosed embodiment, the request for
verification is automatically generated by an application
associated with the identity.
[0011] According to a disclosed embodiment, the determining whether
the credibility score for the identity can be validated by
consensus is based on the subset of the plurality of decentralized
verification services determining credibility scores for the
identity.
[0012] According to a disclosed embodiment, the determining whether
the credibility score for the identity can be validated by
consensus is based on determining whether the credibility score
determined by the first verification service is within a
predetermined range of variance from the credibility scores
determined by the subset of the plurality of decentralized
verification services.
[0013] According to a disclosed embodiment, the determining the
credibility score for the identity includes calculating the
credibility score based on the ledger maintained by the first
verification service.
[0014] According to a disclosed embodiment, the determining the
credibility score for the identity includes requesting that a
resource external to the first verification service calculate the
credibility score.
[0015] According to a disclosed embodiment, the first verification
service is verified to a blockchain network that includes the
plurality of decentralized verification services.
[0016] According to a disclosed embodiment, the identity has a
contract with the blockchain network that includes the credibility
score for the identity.
[0017] According to a disclosed embodiment, the operations further
comprise enabling the identity to communicate with an
access-restricted resource upon verifying the identity.
[0018] According to another disclosed embodiment, a method may be
implemented for passwordless and decentralized verification. The
method may comprise: receiving, at a first verification service,
from among a plurality of decentralized verification services, a
request for verification of an identity, wherein the request
includes no authentication information associated with the
identity; determining, based on a ledger maintained by the first
verification service and shared by the plurality of decentralized
verification services, a credibility score for the identity;
wherein the ledger is developed based on receiving information
associated with a plurality of different types of
credibility-building actions taken by the identity in an
environment; determining whether the credibility score for the
identity can be validated by consensus by at least a subset of the
plurality of decentralized verification services; and determining,
based on whether the credibility score for the identity can be
validated by consensus, whether to verify the identity, wherein the
determination of whether to verify the identity is performed
without using authentication information associated with the
identity.
[0019] According to another disclosed embodiment, the
credibility-building actions include a user associated with the
identity authenticating itself at a physical access point to a
building.
[0020] According to another disclosed embodiment, the
credibility-building actions include a user associated with the
identity communicating electronically with other identities in the
environment.
[0021] According to another disclosed embodiment, the
credibility-building actions include a user associated with the
identity creating electronic files in the environment.
[0022] According to another disclosed embodiment, the
credibility-building actions include a user associated with the
identity modifying electronic files in the environment.
[0023] According to another disclosed embodiment, the
credibility-building actions include a user associated with the
identity performing keyboard input patterns.
[0024] According to another disclosed embodiment, the
credibility-building actions include a user associated with the
identity being authenticated based on biometric information.
[0025] According to another disclosed embodiment, the
credibility-building actions include a user associated with the
identity having certain data stored on a computing device that they
operate.
[0026] According to another disclosed embodiment, the
credibility-building actions include a user associated with the
identity having a certain application stored on a computing device
that they operate.
[0027] According to another disclosed embodiment, the
credibility-building actions include a user associated with the
identity operating a computing device associated with an IP
address.
[0028] According to another disclosed embodiment, the plurality of
decentralized verification services are associated with a single
organization.
[0029] According to another disclosed embodiment, the plurality of
decentralized verification services are associated with a plurality
of separate organizations.
[0030] According to another disclosed embodiment, the plurality of
decentralized verification services are maintained in a cloud
computing environment and each of the plurality of separate
organizations are restricted from accessing decentralized
verification services of others of the plurality of separate
organizations.
[0031] Aspects of the disclosed embodiments may include tangible
computer-readable media that store software instructions that, when
executed by one or more processors, are configured for and capable
of performing and executing one or more of the methods, operations,
and the like consistent with the disclosed embodiments. Also,
aspects of the disclosed embodiments may be performed by one or
more processors that are configured as special-purpose processor(s)
based on software instructions that are programmed with logic and
instructions that perform, when executed, one or more operations
consistent with the disclosed embodiments.
[0032] It is to be understood that both the foregoing general
description and the following detailed description are exemplary
and explanatory only, and are not restrictive of the disclosed
embodiments, as claimed.
BRIEF DESCRIPTION OF THE DRAWINGS
[0033] The accompanying drawings, which are incorporated in and
constitute a part of this specification, illustrate disclosed
embodiments and, together with the description, serve to explain
the disclosed embodiments. In the drawings:
[0034] FIG. 1 is a block diagram of an example system in accordance
with disclosed embodiments.
[0035] FIG. 2 is a block diagram depicting an example process for
providing authentication in an example system in accordance with
disclosed embodiments.
[0036] FIG. 3 is a block diagram depicting an example process for
building user credibility in an example system in accordance with
disclosed embodiments.
[0037] FIG. 4 is a block diagram depicting an example system in
accordance with disclosed embodiments.
[0038] FIG. 5 is a flow diagram depicting an example process for
passwordless and decentralized verification in an example system in
accordance with disclosed embodiments.
DETAILED DESCRIPTION
[0039] In the following detailed description, numerous specific
details are set forth in order to provide a thorough understanding
of the disclosed example embodiments. However, it will be
understood by those skilled in the art that the principles of the
example embodiments may be practiced without every specific detail.
Well-known methods, procedures, and components have not been
described in detail so as not to obscure the principles of the
example embodiments. Unless explicitly stated, the example methods
and processes described herein are not constrained to a particular
order or sequence, or constrained to a particular system
configuration. Additionally, some of the described embodiments or
elements thereof can occur or be performed simultaneously, at the
same point in time, or concurrently.
[0040] Described herein are "no password" or "passwordless"
authentication techniques that operate in a decentralized manner.
Embodiments of the authentication techniques may enable secure
authentication in various types of decentralized frameworks, such
as blockchain implementations, without the need for a user to
manually provide authentication credentials (e.g., username,
password, biometric information, tokens, certificates, keys, etc.).
The authentication techniques may allow users to log into a system,
or authenticate to a different system, without having to remember
or enter authentication credentials.
[0041] The various implementations described herein overcome many
drawbacks of current authentication systems. The described
passwordless authentication system may harden existing systems and
defend against malicious activities. Further, a decentralized
system framework (e.g., blockchain-based) removes the need for a
single repository of credentials and thereby minimizes the risk of
credential harvesting from a single source (e.g., Directory, LDAP,
etc.).
[0042] Reference will now be made in detail to the disclosed
embodiments, examples of which are illustrated in the accompanying
drawings.
[0043] FIG. 1 is a block diagram of an example system 100 in
accordance with disclosed embodiments. As shown, system 100
includes an identity 102 and a secure resource 104, which may be
accessible to identity 102 in an access-restricted manner. System
100 also includes a blockchain network 106 configured to store user
credibility authentication entries 108 (e.g., as a shared ledger),
and a verification service 110. In some embodiments, user
credibility authentication entries 108 may be user credibility
contracts. Identity 102 may be associated with an identity that is
verified by a verification service, as described further below,
thereby authenticating identity 102.
[0044] Identity 102 may be any account, person, or entity
attempting to access a resource, such as a database, server,
storage device, another identity, etc. In other embodiments,
identity 102 may be an automated and/or computerized entity. For
example, a computerized entity may be a scheduled backup service,
task, etc. performed by one or more processors or systems. System
100 may require these automated and/or computerized entities to be
authenticated to the system prior to performing a task. In some
embodiments identity 102 may be authorized to access the resource
104. In other embodiments, identity 102 may not be authorized to
access the resource 104. Identity 102 may be, for example, a local
account on a computer or computer system that is established
according to a particular operating system (e.g., Microsoft
Windows.RTM., Mac OS.RTM., UNIX, etc.), a particular security
service, or another service or protocol governing the computer or
computer system. Identity 102 may also be a network account, such
as an account established according to a network operating system
(e.g., a Microsoft.RTM. network operating system, a Cisco.RTM.
network operating system, a Dell.RTM. network operating system, a
Linux network operating system, etc.). Further, network account
identities may be established based on network security protocols
or services. In addition, identity 102 may be an instance of a
virtual machine or container running in a cloud computing
environment. Identity 102 may also be a token used to identify a
particular computing resource, person, account, virtual machine,
container, or other entity accessing a computer or network.
[0045] Secure resource 104 may be any secure device, application,
database, and/or network that requires an identity (e.g., identity
102) to be authenticated before accessing the resource. Secure
resource 104 may be, for example, a database, a server, an IoT
device, a personal computing device, a smartphone, a vehicle
infotainment system, computer-embedded clothing, a building, an
automated teller machine (ATM), a website, a mobile application, or
various other types of network-accessible resources. In some
embodiments, secure resource 104 may require authentication, such
as through the use of a privileged credential (e.g., password, SSH
key, symmetric (e.g., public/private) key, or other type of
cryptographic data or privileged access token). In accordance with
disclosed embodiments, however, such authentication information, if
any, need not be provided by identity 102.
[0046] Blockchain network 106 is a decentralized system providing
for the storage of distributed ledgers across one or more entities.
Blockchain network 106 may be an existing (public or private)
distributed network formed from and stored by a plurality of
computing devices. The network may be provided or managed by a
service provider, such as BitSE.TM., Blocko.TM., Bloq.TM., Peer
Ledger.TM., or others, or it may be an internal or proprietary
blockchain network. Blockchain network 106 may maintain a
continuously-growing ledger hardened against tampering and revision
and may be composed of data structure blocks that exclusively hold
the data received from verification service 110 or other sources.
In some embodiments, every computing device in blockchain network
106 has a copy of the ledger, thereby ensuring that each ledger is
independently able to assist in performing authentication. In other
embodiments, as discussed further below, only a subset of entities
in blockchain network 106 may have a copy of the ledger.
[0047] The data structure of blockchain network 106 may store data
on one or more identities 102 accessing the blockchain network 106.
For example, a data structure may include historical interaction
data, human access attributes, human/machine response to
challenges, and/or requests. Historical interaction data may
include: [0048] approved requests (e.g., approved log-in requests,
approved building access using an RFID tag, etc.) [0049] rejected
requests (e.g., failed log-in attempts, attempted building access
using an unrecognized RFID tag, etc.) [0050] access time frame
(e.g., how many times the identity has accessed the environment in
a predefined period of time) [0051] accessed services, systems,
and/or applications (e.g., what resources the identity accessed or
attempted to access) [0052] last user interaction (e.g., the last
action the identity completed or attempted in the environment)
[0053] last access time (e.g., the most recent time the identity
was authenticated or attempted to authenticate)
[0054] Human access attributes may include, for example: [0055]
keyboard information (e.g., an identity's typing patterns,
keystroke data, or language usage) [0056] mouse pattern (e.g.,
temporal and spatial patterns associated with an identity's
movement of a mouse) [0057] average typing speed (e.g., an
identity's average words per minute or keystrokes per minute)
[0058] browser type (e.g., an identity's preferred internet
browser) [0059] network location (e.g., an IP address associated
with one or more of an identity's computing devices) [0060]
geographic location (e.g., an identity's GPS location or
coordinates) [0061] device time zone (e.g., the time zone of an
identity based on the location of one or more devices associated
with the identity) [0062] activity time (e.g., the duration of an
identity's session while authenticated to a resource or the
duration of one or more predefined activities, such as the duration
of active Internet browsing or time spent with a document open)
[0063] top applications (e.g., the applications most often opened
by the identity) [0064] startup sequence (e.g., a sequence of
applications being executed or accessed by an identity)
[0065] Data stored of machine and/or human response to challenges
may include, for example: [0066] network delay response (e.g. the
amount of time a network may lag when accessing one or more
resources) [0067] application delay response (e.g., the amount of
time an application may require to process and/or execute a
command) [0068] error message response (e.g., an identity's actions
in response to an error message) [0069] email arrival response
(e.g., whether an entity stores, open, responds to, etc. an email
upon receipt, or the average amount of time before a received email
is read) [0070] open ports response [0071] command response [0072]
shutdown response [0073] restart response
[0074] Request data may include, for example: [0075] login request
data (e.g., how many times an identity attempted to access a
system, whether the log-in attempt was successful, the device from
which the request was made, etc.) [0076] open request [0077]
connection request [0078] service request [0079] voice request
[0080] application request
[0081] The data structure stored by blockchain network 106 may
include any combination of the above described data or other data
collected by one or more blockchain participants.
[0082] Blockchain network 106 may be hosted through the Internet, a
local area network (LAN), a wireless local area network (WLAN), a
wide area network (WAN), a cellular communication network, or any
Internet Protocol (IP) based communication network and the like. In
some embodiments, blockchain network 106 may be based on public
cloud infrastructure, private cloud infrastructure, hybrid
public/private cloud infrastructure, or no cloud infrastructure. In
such differing embodiments, identity 102, secure resource 104, and
verification service 110 may each be in the same, or in different,
networks or network segments.
[0083] Identity authentication entries 108 are stored records
associated with an identity that contain, or allow one to compute,
a credibility score associated with that identity. Credibility
scores refer to data indicating the amount of credibility an
identity has accrued or earned, as discussed further below.
Identity authentication entries 108 may be stored in blockchain
network 106 (e.g., in one or more distributed ledgers belonging to
blockchain network 106). In some embodiments, each operation an
identity (e.g., identity 102) makes on a device or in a network
affects their credibility score. As discussed further below, system
operators may configure the level of credibility, and the number of
blockchain entities that must corroborate that credibility, before
identity 102 is authenticated and able to access secure resource
104.
[0084] Numerous different types of data may be stored in the shared
ledger in blockchain network 106. In some embodiments, these data
are reported to blockchain network 106 in a secure way. For
example, the applications or servers providing such data may be
pre-authenticated to blockchain network 106.
[0085] As an example, in an office environment, the ledger
maintained by multiple entities in blockchain network 106 may store
data regarding various credibility-building actions of identities,
including: [0086] Physical building access (e.g., through radio
frequency identification (RFID) or other near-field communication
techniques, biometric recognition, facial recognition, voice-based
recognition, punch-card or punch-clock access, etc.)
[0087] Workplace location (e.g., office location, office floor,
office department, IP address, MAC address, etc.) [0088] Electronic
communications activity (e.g., email, instant messaging,
videoconferencing, document sharing, etc.) [0089] Applications
stored or executable on a machine of the identity (e.g., based on a
network scan of machines on the network) [0090] Data stored on a
machine of the identity (e.g., based on a network scan of machines
on the network) [0091] Resources accessed (e.g., software
development in a coding environment, IT work in an administrator
environment, financial analysis in a finance environment, marketing
work in a marketing environment, etc.) [0092] Attendance at
meetings (e.g., project meetings, training meetings, educational
meetings, division meetings, etc.)
[0093] Further, in a school environment, the ledger maintained in
blockchain network 106 may store data regarding
credibility-building actions of identities, including: [0094]
Attendance information (e.g., based on building entry techniques,
manually entered attendance reports, etc.) [0095] Authentication
for purposes of taking tests [0096] Transactions at a library
(e.g., books loaned, on loan, returned, etc.) [0097] Transaction at
a cafeteria (e.g., items purchased, returned, etc.)
[0098] As another example, in an online banking embodiment, the
ledger maintained in blockchain network 106 may store data
regarding credibility-building actions of identities, including:
[0099] Time of log-in and log-off [0100] Accounts viewed [0101]
Transactions requested (e.g., transfer, deposit, bill pay, etc.)
[0102] Updates to personal information [0103] Additions of new
accounts [0104] Additions of new account features
[0105] Further, as an additional example, in a social media
environment, the ledger maintained in blockchain network 106 may
store data regarding credibility-building actions of identities,
including: [0106] Time of sign-in and sign-out [0107] Media posted
(e.g., text, photos, videos, etc.) [0108] Media consumed (e.g.,
text, photos, videos, web pages, etc.) [0109] Updates to user
profile [0110] Updates to social media preferences
[0111] In another example, in a hospital environment, the ledger
maintained in blockchain network 106 may store data regarding
credibility-building actions of identities, including: [0112] Shift
sign in and sign out [0113] Hospital unit assignments [0114]
Medical certifications and credentials [0115] Hospital requests for
patients (e.g., requests for consultations, transfers, diagnostic
procedures, etc.) [0116] Access to restricted areas
[0117] In this example, the blockchain network 106 may also store
data regarding credibility-building actions of patients, including:
[0118] Signing into and out of a hospital building [0119] Entering
a parking lot [0120] Hospital ID bracelet being scanned by a doctor
or nurse during rounds [0121] Purchasing prescribed medication at a
pharmacy
[0122] In some embodiments, a determination is made of what
information to store in the shared ledger, what information (if
any) to store remotely, and what information (if any) to delete.
Due to storage constraints, for example, it may be desirable to
limit the amount of storage required in the common ledger. One
technique, for example, may be to store only the most recent (e.g.,
last 100 days, most recent 100 credibility-building actions, etc.)
data. Another technique may be to generate data descriptive of
credibility-building actions and store that data rather than the
actual credibility-building actions themselves. For example,
descriptive data may include averages of credibility-building
actions, sum totals of credibility-building actions, sum totals of
credibility-building actions over predefined time periods, etc.
Similarly, a determination may be made to store
credibility-building action data in a storage resource remote from
the ledger if storage space becomes a constraint. In such
embodiments, for example, verification service 110 or blockchain
network 106 may determine what data to store locally in the ledger
and what data to store remotely at the storage resource. Using such
techniques, the most recent data, or the most probative data for
computing a credibility score, may be stored locally on the ledger
and older or less probative data may be stored remotely, e.g., in a
cloud-based storage system or external database. In some
embodiments, data stored remotely may be accessible for business
analytics.
[0123] Verification service 110 may be software (e.g., a standalone
application, an integrated agent, etc.), that communicates with
identity 102 and a blockchain-based or other decentralized network
(e.g., blockchain network 106). In some embodiments, verification
service 110 is installed on devices (e.g., a machine running
identity 102) or resources connected to blockchain network 106.
Verification service 110 may be part of a service stored on the
computing devices participating in blockchain network 106. In some
embodiments, verification service 110 executes transparently to
identity 102 or an operating system of identity 102. As discussed
further below, verification service 110 may be configured to
receive requests from identity 102 for access to secure resource
104. In such embodiments, the requests may be addressed to
verification service 110 or, alternatively, verification service
110 may be configured to intercept such requests (e.g., intercept
them from an application running on the same machine as identity
102, or from an operating system of the machine). Further,
verification service 110 can either automatically or manually
receive requests from identity 102 for access to secure resource
104. For example, if an application is seeking to access secure
resource 104, the process may be automatic, whereas if a user is
seeking to access secure resource 104, the request may be manually
sent by the user.
[0124] In some embodiments, verification service 110 is installed
on multiple entities in blockchain network 106. For example, if an
enterprise has a blockchain network 106 that it is operating, each
participating entity in the network may have a verification service
110. Further, as discussed below, in some embodiments, multiple
different enterprises or organizations may seek to secure share a
single blockchain network 106, such that a sufficient number of
entities are participating and able to develop a consensus about
authentication decisions. Regardless of the number of enterprises
or organizations, verification service 110 may have access to a
ledger, an identity contract 108, or both. For example, the ledger
and identity contract 108 may be stored on the same device as
verification service, or stored separately in blockchain network
106.
[0125] FIG. 2 is an illustration of a process 200 for
authenticating a user in an embodiment of the passwordless
authentication system (e.g., system 100). Process 200 may be
invoked manually (e.g., by a user) or automatically (e.g., by an
application). In some embodiments, a user (e.g., associated with
identity 102) may attempt to log in to a secure resource (e.g.,
secure resource 104) via an application 202. The application 202
receives the log in request from the user and sends an
authentication request 204 to internal authentication service agent
206, which may be an example of verification service 110 that is
integrated into a device running identity 102. Application 202 may
be any software seeking access to a secure resource. In accordance
with disclosed embodiments, authentication request 204 includes no
authentication credentials associated with the user.
[0126] According to process 200, internal authentication agent 206
may further receive authentication request 204, indicating that an
identity is initiating a procedure to access a secure resource.
Based on the authentication request 204, internal authentication
agent 206 may communicate a query 208 to retrieve the user
credibility score from the blockchain ledger holders 210. The
blockchain ledger holders 210 may each have a copy of the ledger
stored on the blockchain network (e.g., blockchain network 106)
that contains data including credibility-building information and
user credibility authentication entries 108, as discussed
above.
[0127] In some embodiments, internal authentication service agent
206 calculates the credibility score of the identity seeking access
to the secure resource. In further embodiments, the credibility
score is calculated by one or more of the blockchain ledger holders
210.
[0128] Various techniques may be used for calculating the
credibility score. For example, based on all of the
credibility-building information stored in the ledger, the number
of credibility-building actions of the identity may be counted and
quantified as a numerical score (e.g., 80/100, or 80%, or 0.8). In
further embodiments, the different credibility-building actions may
receive different weights that factor differently into the
calculation. For example, in the environment of an office discussed
above, data regarding an identity entering a physical building may
receive a higher weight than data regarding applications stored on
the identity's machine. Further, in some embodiments, the number of
times a credibility-building action has occurred can affect its
weight. For example, if an identity regularly enters an office
building through a physical authentication process between 8:30 am
and 9:00 am at least 90% of work days, that credibility-building
action may be given more weight than other factors with more
variability. In further embodiments, a credibility score for an
identity may be weighted so that certain time periods of
credibility-building actions (e.g., more recent or less recent) may
be given more weight. Thus, if an identity is determined to have a
new working pattern (e.g., a new project), the credibility-building
action of communicating with a new team may be given more weight
than a previous credibility-building action (e.g., communicating
with a prior team). In additional embodiments, additional weight
may be given in a credibility score if an identity has a
significant number of different types of credibility-building
actions. For example, while having a single credibility-building
action can result in a first weight, a second (higher) weight can
be applied in the identity has four different credibility-building
actions reflected in the ledger.
[0129] In addition to calculating credibility scores, the
environment may also calculate the credibility score threshold
required to access the environment. In other embodiments, the
credibility score threshold may be calculated and/or set by a
system administrator. In further embodiments, the different
credibility score threshold may receive different weights
corresponding to different parameters that factor differently into
the calculation. For example, an identity attempting to access a
database storing personally identifiable information may be
required to meet a higher credibility score threshold than if that
identity were attempting to access an email server from a local
network. Thus, the sensitivity of data stored by a resource may
affect the credibility score threshold of that resource. In some
embodiments, the credibility score threshold may be a configurable,
static value, or may be a dynamic value that changes as a function
of time. For example, the credibility score threshold may be higher
for an environment with few participants compared to an environment
with a large number of participants, and may change if the number
of participants in the environment changes. In another example, the
credibility score threshold may increase in response to a detected
cybersecurity threat and may decrease after a period of time in
which no cybersecurity threats or attacks were detected.
[0130] Continuing with process 200, query 208 may fetch the
calculated credibility score of the identity from the blockchain
ledger holders 210. The retrieved credibility score is then
validated by a consensus-seeking approach involving a fixed number
of the ledger holders 210. The query result may be validated by
confirming the query result matches the result from executing the
same query on the locally stored ledger of each entity in
blockchain network 106. In some embodiments, a predefined number or
percentage of ledger holders 210 must provide the identical
credibility score in order to achieve consensus. In other
embodiments, the credibility scores need not be identical but must
fall within a predefined tolerance (e.g., 1% or 5%). The query
result may also be validated using other methods for example, by
the practical byzantine fault tolerance algorithm (PBFT) or
Proof-of-Stake (POS). The validation of the query results may be
executed locally on each participating entity (e.g., by a
locally-stored agent on each entity).
[0131] After the credibility score of the identity is validated by
consensus in blockchain network 106, the information validation
consensus result 212 is sent to the internal authentication service
agent 206, which may then decide whether the level of consensus is
sufficient to authenticate the identity, using the approaches
discussed above. If the identity's credibility score was validated
by consensus by blockchain network 106, internal authentication
service agent 206 may send an authentication request result 214 to
the application, allowing the identity to access the secure device.
This may involve opening a secure communications channel between
the identity and the secure device, using a proxy resource (e.g.,
intermediary application or server) to log the identity in to the
secure device, or other techniques of secure access. On the other
hand, if the identity's credibility score was not validated, the
authentication request result 214 will communicate with the
application 202 such that the identity is denied access to the
secure resource. In some embodiments, the identity's credibility
score may be validated, but may be too low to access the secure
device and the authentication request will be denied.
[0132] FIG. 3 depicts an exemplary process 300 through which an
identity 302 may build or lose credibility, with a consequence of
increasing or decreasing their credibility score. In some
embodiments, identity 302 (e.g., similar to identity 102 described
in connection with FIG. 1) may interact with a device in a network.
The network may include, for example, devices that authenticate
themselves or a corresponding identity using RFID or other NFC
techniques, such as a sensor at a building entrance. For example,
when a user scans their security badge or fob containing an RFID or
NFC chip at the sensor, the user, via the RFID or NFC chip, may be
authenticated and the entrance to the building allowed or
acknowledged. The action of being authenticated by the building
sensor, which is part of the network, may increase the user's
credibility score, in accordance with the various credibility score
computation techniques discussed above.
[0133] In some embodiments, the credibility score required to
access the secure resource may be adjustable in accordance with
system policies. For example, if the secure resource is a highly
sensitive software development server, a higher credibility score
may be required than for access to an organization's informational
intranet site. The required security score may be set, for example,
by the authentication agent or the secure resource. In certain
embodiments, the entity controlling the secure resource may also
configure what devices are part of the network and what types of
interactions with these devices increase a user's credibility
score.
[0134] When identity 302 is successfully authenticated by a device
and/or system in the network, the authenticated and validated
interaction 304 and associated data may be sent to an authenticator
agent 306. Authenticator agent 306 may receive the data indicative
of the user's authentication and communicate with blockchain ledger
308 to increase or decrease the user's credibility score 310 (e.g.,
as stated in, or derivable from, a user's credibility contract).
Blockchain ledger 308 may be a part of blockchain network 106
discussed above, with a copy of the ledger 308 being stored on each
computing device participating in the network 106. In some
embodiments, an unauthenticated attempt to access a secure resource
may decrease a user's credibility score. Further, in accordance
with the above techniques of computing a credibility score, certain
actions may lead to a lower score (e.g., taking an affirmative
action determined to be negative, such as breaching a network
security policy, attempting to access a network resource for which
the user lacks permissions, copying or deleting system files,
etc.).
[0135] In an exemplary embodiment of a passwordless authentication
system, e.g., system 100, an employee may authenticate to one or
more secure networks and/or databases from his personal computer in
an office setting. When the employee brings his personal computer
to the office, the employer may require that the employee's
identity be authenticated before the employee can access company
resources. An employee may wish to access a proprietary database
from his personal computer while working in the office. The
employee may initiate an application or open a folder accessing the
database and an authentication request is sent from the application
requesting authentication to an internal service agent managed by
the employer. The employee's credibility score, stored in the
employee's identity contract, is retrieved from the employer's
blockchain ledger holder. Upon retrieval, the computing devices
participating in the blockchain network validate the employee's
identity contract by consensus. Once the identity contract is
validated, the employee's credibility score may be measured against
a threshold set by the employer. If the employee's credibility
score meets the employer's requirements, the internal
authentication service agent sends confirmation of the
authentication to the employee's personal computer, allowing him to
access one or more secure resources without logging into the
employer's network with a password and username.
[0136] In some embodiments, consensus between the blockchain
participants may be reached using one or more techniques of voting.
In other embodiments, consensus may be configured to give more
weight to some participants and less weight to others. For example,
a system may include veto certain participants, prioritize premium
participants, and differently assess lower-grade, or standard,
participants. A veto participant may be a trusted participant able
to veto consensus. An exemplary trusted participant may be a secure
device. A premium participant may be given a higher weight in the
consensus algorithm to protect from consensus hijacking by
attackers. A premium participant may be configured, or predefined,
as a premium participant or may accrue premium status by building
credibility as previously described. In other embodiments, a
participant's weight in the consensus algorithm may vary over time.
For example, a lower-graded participant's weight in the consensus
algorithm may increase as the lower-grade participant's credibility
score increases, thus preventing a newly joined participant without
proven credibility from influencing consensus.
[0137] In this example, the employer may identify a certain
credibility score required by an employee. The employee's identity
contract must contain at least the certain credibility score to be
verified by the employer's authentication agent. The employer may
additionally determine what actions taken by the employee increase
the employee's credibility score and by what amount. For example,
accessing an office building or area of an office building
authenticated RFID badge may increase an employee's credibility
score. Other actions, such as electronic communication activity,
may also increase credibility score, but may be weighted less than
authentication associated with an employee's presence at a physical
location. When the employee completes a validated interaction, the
authenticator agent communicates with the employer's shared ledger
to update and store the employee's new credibility score.
[0138] In another example, the passwordless authentication system
may be used to authenticate a student to take a test at university.
In this example the student may be required to authenticate to the
university network to access the exam or to document attendance.
For example, a student may open an exam portal to take an exam on
their computing device. The exam portal application communicates
with the internal service authentication agent of the university to
retrieve the student's credibility score from the university's
ledger. If the student is validated, both by consensus of the
ledger and sufficient credibility score, the internal
authentication service agent communicates with the exam portal
application to allow the student to access the exam.
[0139] The student may build his credibility score, for example, by
scanning a student identification card at the beginning of each
class, by purchasing supplies at the university bookstore, or by
electronically turning in homework assignments. Each student at the
university may have an identity contract stored in the university's
distributed ledger. The university may set up the required
credibility scores such that each of the offered courses has a
different threshold for authentication. As an example, a student
must have authenticated at the appropriate classroom at each class
meeting to be authenticated to access the final exam. The required
credibility score and associated interactions to increase/decrease
the credibility score may be customized by school officials or
professors.
[0140] In yet another example, a passwordless authentication system
may be used to authenticate a user to a social media account, e.g,
Facebook.RTM., Twitter.RTM., Instagram.RTM., LinkedIn.RTM., etc.
When logging in to a social media account a user is normally
prompted to enter a username and password and/or complete other
multi-factor authentication steps. Through an embodiment of the
passwordless authentication system, the user may log in to a social
media account without entering authentication information or
credentials. For example, when the user opens the social media
application on a smart device, the application communicates with
the application's internal authentication service agent. In turn,
the internal authentication service agent queries the application's
blockchain ledger to retrieve the user's identity contract and
credibility score. If the user's credibility score meets the
application's threshold credibility score, internal authentication
service agent communicates with the social media application giving
the user access to his account.
[0141] The user may increase his credibility score by completing
authenticated interactions such as logging in to an account,
posting a photo to an account, and/or navigating to sponsored
content through the social media application. Certain interactions
may also decrease the user's credibility score. For example,
attempts to log in to an account with an incorrect password or
communicating with members of the social media application outside
the user's network of friends and/or followers may decrease the
user's credibility score. In one example, a number of social media
platforms may share a distributed ledger to allow users to
authenticate themselves across platforms.
[0142] In another example, a passwordless authentication system may
be used to authenticate a hospital employee, e.g., a doctor or
nurse, to access HIPPA-protected patient information. In this
example the employee may be required to authenticate to the
hospital database and network to access patient data or submit
requests for diagnostics, prescriptions, or consultations with
specialists on behalf of a patient. For example, a hospital
employee may open a portal at a workstation in a hospital. The
workstation communicates with the internal service authentication
agent of the hospital to retrieve the employee's credibility score
from the hospital's ledger. If the employee is validated, both by
consensus of the ledger and sufficient credibility score, the
internal authentication service agent communicates with the
workstation to allow the employee to access the patient's
information and records. In some embodiments, for example, in
hospitals or doctors' offices, certain consensus algorithms and/or
credibility scores may be implemented to comply with privacy
regulations, e.g. HIPPA laws.
[0143] The hospital employee may increase his credibility score,
for example, by scanning a hospital identification card to gain
access to restricted areas, by verifying medical credentials and/or
certifications with the hospital system, by signing in or out of
shift, or by executing tasks such as scanning patients' hospital ID
tags during rounds. Each employee at the hospital may have an
identity contract stored in the hospital's distributed ledger. The
hospital may set up its authentication requirements such that
different areas of the hospital have a different threshold for
authentication. As an example, an employee must have current and
official credentials or certifications to enter an operating room
for surgery, but a lower level of credentials or certifications to
access an employee break room. The required credibility score and
associated interactions to increase/decrease the credibility score
may be customized by hospital officials or may be mandated by local
laws and regulations.
[0144] In another example, the passwordless authentication system
may be used to authenticate an identity associated with one or more
Internet of Things (loT) devices, e.g., a smart car, smart home,
GPS, etc. In these examples, the identity may be required to
authenticate to a database and network to access spaces, such as an
office building parking garage, vehicle, home, etc. For example, an
employee may be driving a vehicle enabled with RFID technology to
work. The employee may attempt to enter a garage to park the
vehicle. Instead of validating the employee, for example, with an
identification badge, the garage may read the RFID tag of the
vehicle. If the vehicle is validated, both by consensus of the
ledger and sufficient credibility score, the internal
authentication service agent may communicate with parking garage to
allow the employee to enter.
[0145] A vehicle may increase its credibility score, for example,
by entering and exiting a garage at times corresponding to when its
driver signed into and out of an office building or by being locked
and unlocked by a device associated with the driver. The employer
may set up the required credibility scores to enter a garage. In
some examples, a third-party management company may operate the
garage and may require an employee to authenticate with the
employer's network before entering the garage.
[0146] In some embodiments, such as the example above in which a
third-party entity may require an identity to authenticate with a
blockchain network, a third-party may have access to an external
endpoint API of another entity's blockchain network. To
authenticate an identity, the third-party may need to communicate
with a primary entity's ledger to validate an identity's
credentials. To maintain security, a third-party system may be
enabled to access an external endpoint of the blockchain to
complete an authentication of an identity.
[0147] The above described processes 200, 300 for authenticating a
user and building credibility may, in some embodiments, be employed
in a cloud computing environment 402 shared by one or more entities
404, 406, 408, as shown FIG. 4. Cloud computing environment 402 may
be hosted on a cloud service platform, such as those offered by,
for example, Amazon.RTM., Apple.RTM., Cisco.RTM., Citrix.RTM.,
IBM.RTM., Joyent.RTM., Google.RTM., Microsoft.RTM., Rackspace.RTM.,
Salesforce.com.RTM., and Verizon.RTM./Terremark.RTM., or other
types of cloud services. An entity may be any organization,
corporation, person, service, application, or government sharing
one or more internal networks. In some instances, a single entity
(e.g., entity 404) may have a small number of verification
services, but not enough to determine verification of an identity
by consensus. For example, if entity 404 requires at least 100
blockchain participants to authenticate an identity by consensus
but only has 10 participants in its organization, it may be unable
to participate in decentralized authentication. Nevertheless, by
collaborating with other entities (e.g., 406 and 408), entity 404
may be able to scale up the number of blockchain participants
available for authentication by consensus. These entities 404, 406,
408 may each share a common ledger 410 hosted in cloud computing
environment 402. In some embodiments, the entities 404, 406, 408
may each have an encrypted copy of the ledger 410, and may be
restricted from accessing the verification services of the other
entities. In this way, entities 404, 406, and 408 will not be able
to access each other's confidential information. Such information
may be maintained securely in the cloud environment 402.
[0148] As described above, in some embodiments, a single entity
(e.g., entity 404) may have a small number of verification
services, but not enough to determine verification of an identity
by consensus. For example, if entity 404 requires at least 100
blockchain participants to authenticate an identity by consensus
but only has 10 participants in its organization, it may be unable
to participate in decentralized authentication. In one embodiment,
one or more servers belonging to the entity 404 may emulate virtual
participants. This may involve, for example, creating records
(e.g., contracts, ledgers, etc.) associated with such virtual
participants. Alternatively, it may involve developing real or
virtual machines (e.g., VMs or docker containers) to emulate
blockchain participants. By emulating participants, the entity 404
may avoid possible consensus weaknesses by establishing a majority
and thus preventing an attacker from injecting its own participants
into the blockchain network. In some embodiments, the virtual
participants may be granted veto privileges or may be defined as
premium participants, as described above.
[0149] FIG. 5 is an exemplary process 500 for authenticating a
user, e.g., identity 102 or identity 302. A first verification
service, e.g., a verification service running verification service
110, internal authentication service agent 206, and/or
authentication agent 306, may receive a request for verification of
an identity, e.g., an identity associated with a user, from one of
a plurality of decentralized verification services (step 502). In
some embodiments, the identity may have a contract, e.g., user
credibility contract 108, with the blockchain network, e.g.,
blockchain network 106, that includes or can be used to calculate
the credibility score for the identity. In some embodiments, the
plurality of decentralized verification services may be associated
with a single organization, or entity. In other embodiments, as
described with reference to FIG. 4, the plurality of decentralized
verification services may belong to more than one organization, or
entity. In some embodiments, the plurality of decentralized
verification services are maintained in a cloud computing
environment, e.g., environment 402, and each of the plurality of
separate organizations are restricted from accessing decentralized
verification services of others of the plurality of separate
organizations.
[0150] In some embodiments, the identity requests verification from
the verification service, which may be verified to a blockchain
network including decentralized verification services. In other
embodiments, the request for verification is automatically
generated by an application associated with the identity. The
request received by the verification service may not contain any
authentication information (e.g., a password, token, key, etc.)
associated with the identity. In some embodiments, the verification
service may be configured to determine what information to store in
the ledger and what information to store external to the
ledger.
[0151] The credibility score of the identity may be determined
based on a ledger maintained by the first verification service and
shared by the plurality of decentralized verification services, a
credibility score for the identity (step 504). The ledger may be a
ledger shared by computing devices participating in a blockchain
network, e.g., blockchain network 106. In some embodiments,
determining the credibility score for the identity includes
calculating the credibility score based on the ledger maintained by
the first verification service (e.g., the ledger local to the
verification service). In some embodiments, determining the
credibility score for the identity includes requesting that a
resource external to the first verification service calculate the
credibility score.
[0152] In some embodiments, the ledger is developed based on
receiving information associated with a plurality of different
types of credibility-building actions taken by the identity in an
environment, as described previously with reference to FIG. 3. For
example, credibility-building actions may include a user associated
with the identity authenticating himself at a physical access point
to a building, communicating electronically with other identities
in the environment, creating electronic files in the environment,
modifying electronic files in the environment, performing keyboard
input patterns, being authenticated based on biometric information,
having certain data stored on a computing device that they operate,
having a certain application stored on a computing device that they
operate, and/or operating a computing device associated with an IP
address.
[0153] The system may determine whether the credibility score for
the identity can be validated by consensus by at least a subset of
the plurality of decentralized verification services (step 506). In
some embodiments, whether the credibility score for the identity
can be validated by consensus is based on the subset of the
plurality of decentralized verification services determining
credibility scores for the identity. In some embodiments, the
determination of whether the credibility score for the identity can
be validated by consensus is based on determining whether the
credibility score determined by the first verification service is
within a predetermined range of variance (e.g., 1%, 5%, etc.) from
the credibility scores determined by the subset of the plurality of
decentralized verification services. Further, as discussed above, a
predetermined number or percentage of verification services must
participate in the consensus-seeking determination in some
embodiments.
[0154] Based on whether the credibility score for the identity can
be validated by consensus, the system may determine whether to
verify the identity (step 508). In some embodiments, the
determination of whether to verify the identity is performed
without using authentication information associated with the
identity. In some embodiments, determining whether to verify the
identity may include determining whether to authenticate the
identity. In some embodiments, the identity's credibility score may
be adjusted based on the determination of whether to verify the
identity.
[0155] If the identity is verified, the system may allow and/or
enable the identity to communicate with an access-restricted
resource, e.g., secure resource 104. As discussed above, this may
involve opening a secure communication channel (e.g., tunnel,
reverse tunnel, encrypted session, etc.) between the identity and
the secure resource, proxying a connection between the identity and
the secure resource, or other techniques.
[0156] It is to be understood that the disclosed embodiments are
not necessarily limited in their application to the details of
construction and the arrangement of the components and/or methods
set forth in the following description and/or illustrated in the
drawings and/or the examples. The disclosed embodiments are capable
of variations, or of being practiced or carried out in various
ways.
[0157] The disclosed embodiments may be implemented in a system, a
method, and/or a computer program product. The computer program
product may include a computer readable storage medium (or media)
having computer readable program instructions thereon for causing a
processor to carry out aspects of the present invention.
[0158] The computer readable storage medium can be a tangible
device that can retain and store instructions for use by an
instruction execution device. The computer readable storage medium
may be, for example, but is not limited to, an electronic storage
device, a magnetic storage device, an optical storage device, an
electromagnetic storage device, a semiconductor storage device, or
any suitable combination of the foregoing. A non-exhaustive list of
more specific examples of the computer readable storage medium
includes the following: a portable computer diskette, a hard disk,
a random access memory (RAM), a read-only memory (ROM), an erasable
programmable read-only memory (EPROM or Flash memory), a static
random access memory (SRAM), a portable compact disc read-only
memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a
floppy disk, a mechanically encoded device such as punch-cards or
raised structures in a groove having instructions recorded thereon,
and any suitable combination of the foregoing. A computer readable
storage medium, as used herein, is not to be construed as being
transitory signals per se, such as radio waves or other freely
propagating electromagnetic waves, electromagnetic waves
propagating through a waveguide or other transmission media (e.g.,
light pulses passing through a fiber-optic cable), or electrical
signals transmitted through a wire.
[0159] Computer readable program instructions described herein can
be downloaded to respective computing/processing devices from a
computer readable storage medium or to an external computer or
external storage device via a network, for example, the Internet, a
local area network, a wide area network and/or a wireless network.
The network may comprise copper transmission cables, optical
transmission fibers, wireless transmission, routers, firewalls,
switches, gateway computers and/or edge servers. A network adapter
card or network interface in each computing/processing device
receives computer readable program instructions from the network
and forwards the computer readable program instructions for storage
in a computer readable storage medium within the respective
computing/processing device.
[0160] Computer readable program instructions for carrying out
operations of the present invention may be assembler instructions,
instruction-set-architecture (ISA) instructions, machine
instructions, machine dependent instructions, microcode, firmware
instructions, state-setting data, or either source code or object
code written in any combination of one or more programming
languages, including an object oriented programming language such
as Smalltalk, C++ or the like, and conventional procedural
programming languages, such as the "C" programming language or
similar programming languages. The computer readable program
instructions may execute entirely on the user's computer, partly on
the user's computer, as a stand-alone software package, partly on
the user's computer and partly on a remote computer or entirely on
the remote computer or server. In the latter scenario, the remote
computer may be connected to the user's computer through any type
of network, including a local area network (LAN) or a wide area
network (WAN), or the connection may be made to an external
computer (for example, through the Internet using an Internet
Service Provider). In some embodiments, electronic circuitry
including, for example, programmable logic circuitry,
field-programmable gate arrays (FPGA), or programmable logic arrays
(PLA) may execute the computer readable program instructions by
utilizing state information of the computer readable program
instructions to personalize the electronic circuitry, in order to
perform aspects of the present invention.
[0161] Aspects of the present invention are described herein with
reference to flowchart illustrations and/or block diagrams of
methods, apparatus (systems), and computer program products
according to embodiments of the invention. It will be understood
that each block of the flowchart illustrations and/or block
diagrams, and combinations of blocks in the flowchart illustrations
and/or block diagrams, can be implemented by computer readable
program instructions.
[0162] These computer readable program instructions may be provided
to a processor of a general purpose computer, special purpose
computer, or other programmable data processing apparatus to
produce a machine, such that the instructions, which execute via
the processor of the computer or other programmable data processing
apparatus, create means for implementing the functions/acts
specified in the flowchart and/or block diagram block or blocks.
These computer readable program instructions may also be stored in
a computer readable storage medium that can direct a computer, a
programmable data processing apparatus, and/or other devices to
function in a particular manner, such that the computer readable
storage medium having instructions stored therein comprises an
article of manufacture including instructions which implement
aspects of the function/act specified in the flowchart and/or block
diagram block or blocks.
[0163] The computer readable program instructions may also be
loaded onto a computer, other programmable data processing
apparatus, or other device to cause a series of operational steps
to be performed on the computer, other programmable apparatus or
other device to produce a computer implemented process, such that
the instructions which execute on the computer, other programmable
apparatus, or other device implement the functions/acts specified
in the flowchart and/or block diagram block or blocks.
[0164] The flowcharts and block diagrams in the Figures illustrate
the architecture, functionality, and operation of possible
implementations of systems, methods and computer program products
according to various embodiments of the present invention. In this
regard, each block in the flowcharts or block diagrams may
represent a software program, segment, or portion of code, which
comprises one or more executable instructions for implementing the
specified logical function(s). It should also be noted that, in
some alternative implementations, the functions noted in the block
may occur out of the order noted in the figures. For example, two
blocks shown in succession may, in fact, be executed substantially
concurrently, or the blocks may sometimes be executed in the
reverse order, depending upon the functionality involved. It will
also be noted that each block of the block diagrams and/or
flowchart illustration, and combinations of blocks in the block
diagrams and/or flowchart illustration, can be implemented by
special purpose hardware-based systems that perform the specified
functions or acts, or combinations of special purpose hardware and
computer instructions.
[0165] The descriptions of the various embodiments of the present
invention have been presented for purposes of illustration, but are
not intended to be exhaustive or limited to the embodiments
disclosed. Many modifications and variations will be apparent to
those of ordinary skill in the art without departing from the scope
and spirit of the described embodiments. The terminology used
herein was chosen to best explain the principles of the
embodiments, the practical application or technical improvement
over technologies found in the marketplace, or to enable others of
ordinary skill in the art to understand the embodiments disclosed
herein.
[0166] It is expected that during the life of a patent maturing
from this application many relevant virtualization platforms,
virtualization platform environments, trusted cloud platform
resources, cloud-based assets, protocols, communication networks,
security tokens and authentication credentials will be developed
and the scope of the these terms is intended to include all such
new technologies a priori.
[0167] It is appreciated that certain features of the invention,
which are, for clarity, described in the context of separate
embodiments, may also be provided in combination in a single
embodiment. Conversely, various features of the invention, which
are, for brevity, described in the context of a single embodiment,
may also be provided separately or in any suitable subcombination
or as suitable in any other described embodiment of the invention.
Certain features described in the context of various embodiments
are not to be considered essential features of those embodiments,
unless the embodiment is inoperative without those elements.
[0168] Although the invention has been described in conjunction
with specific embodiments thereof, it is evident that many
alternatives, modifications and variations will be apparent to
those skilled in the art. Accordingly, it is intended to embrace
all such alternatives, modifications and variations that fall
within the spirit and broad scope of the appended claims.
* * * * *