U.S. patent application number 17/228152 was filed with the patent office on 2022-09-29 for group signatures for a smart wallet on a blockchain platform.
The applicant listed for this patent is 0Chain Corp.. Invention is credited to Saswata Basu, Siva Dirisala.
Application Number | 20220309490 17/228152 |
Document ID | / |
Family ID | 1000005771118 |
Filed Date | 2022-09-29 |
United States Patent
Application |
20220309490 |
Kind Code |
A1 |
Basu; Saswata ; et
al. |
September 29, 2022 |
GROUP SIGNATURES FOR A SMART WALLET ON A BLOCKCHAIN PLATFORM
Abstract
The systems and methods on a blockchain platform for one or more
intermediaries for services including proxy re-encryption,
independent audit, multiple-signatures based smart wallet
associated with a smart contract and split-key authentication to
achieve secure passwordless login. Proxy re-encryption by receiving
a ciphertext from a first user with condition parameters that has
been encrypted with a dynamically selected encryption algorithm.
Audit service receiving an encrypted file from a user for storage
on the blockchain platform; enforcing the security policy
parameters for all access requests to the file on the blockchain
platform; and optionally providing audit report of the encrypted
file storage and access. A smart wallet with a group key using
multiple signatures based on receipt of a threshold number of
signatures. Split-key authentication by splitting the private key
into two or more parts; and assigning the split private key part to
two or more client devices.
Inventors: |
Basu; Saswata; (Cupertino,
CA) ; Dirisala; Siva; (Cupertino, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
0Chain Corp. |
Cupertino |
CA |
US |
|
|
Family ID: |
1000005771118 |
Appl. No.: |
17/228152 |
Filed: |
April 12, 2021 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
16369656 |
Mar 29, 2019 |
|
|
|
17228152 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06Q 20/3674 20130101;
G06Q 2220/00 20130101 |
International
Class: |
G06Q 20/36 20060101
G06Q020/36 |
Claims
1-7. (canceled)
8. A method of a blockchain platform for a smart wallet,
comprising: assigning a total number of two or more public-private
key pairs for users associated with the smart wallet; allocating a
threshold number for approval on transaction on the smart wallet
wherein the threshold number is less than or equal to the total
number; creating a group key from the total number of
public-private keys and the threshold number for approvals; using
the group key to register the smart wallet on the blockchain;
receiving for a transaction a shared signature based on the group
key from two or more users; and validating and finalizing the
transaction when the received signatures are more than the
threshold number.
9. The method of claim 8, wherein: the smart wallet with the group
key supports all the functions of a single user wallet.
10-17. (canceled)
18. A system of a blockchain platform for a smart wallet,
comprising: one or more processors; a memory coupled to at least
one of the processors; a network interface that connects the local
node to one or more remote nodes; and a set of computer program
instructions stored in the memory and executed by at least one of
the processors in order to perform actions comprising: assign a
total number of two or more public-private key pairs for users
associated with the smart wallet; allocate a threshold number for
approval on transaction on the smart wallet wherein the threshold
number is less than or equal to the total number; create a group
key from the total number of public-private keys and the threshold
number for approvals; use the group key to register the smart
wallet on the blockchain; receive for a transaction a shared
signature based on the group key from two or more users; and
validate and finalize the transaction when the received signatures
are more than the threshold number.
19. The system of claim 18, wherein: the smart wallet with the
group key supports all the functions of a single user wallet.
20. (canceled)
Description
RELATED APPLICATIONS
[0001] This application is related to co-pending patent application
Ser. No. 16/247,994 filed on Jan. 15, 2019.
[0002] If an Application Data Sheet (ADS) has been filed on the
filing date of this application, it is incorporated by reference
herein. Any applications claimed on the ADS for priority under 35
U.S.C. .sctn. .sctn. 119, 120, 121, or 365(c), and any and all
parent, grandparent, great-grandparent, etc. applications of such
applications, are also incorporated by reference, including any
priority claims made in those applications and any material
incorporated by reference, to the extent such subject matter is not
inconsistent herewith.
CROSS-REFERENCE TO RELATED APPLICATIONS
[0003] The present application is related to and/or claims the
benefit of the earliest available effective filing date(s) from the
following listed application(s) (the "Priority Applications"), if
any, listed below (e.g., claims earliest available priority dates
for other than provisional patent applications or claims benefits
under 35 USC .sctn. 119(e) for provisional patent applications, for
any and all parent, grandparent, great-grandparent, etc.
applications of the Priority Application(s)). In addition, the
present application is related to the "Related Applications," if
any, listed below.
FIELD OF THE INVENTION
[0004] The present invention is in the technical field of cloud
computing. More particularly, the present invention is in the
technical field of blockchain platform. More particularly, the
present invention is in the technical field of proxy re-encryption,
multiple signatures and passwordless login or authentication using
split keys on a blockchain platform.
BACKGROUND
[0005] Internet is a global computer network providing a variety of
information and communication facilities, consisting of
interconnected networks using standardized communication protocols.
Internet is not owned by a single entity and it operates without a
central governing body. The same principles of distributed
governance were applied to digital currencies by providing ability
to perform digital transactions that existed without support from
any underlying institution. The digital ledger that records the
transactions in a chain using a mathematical hierarchy is called a
blockchain. The following paragraphs describe different scenarios
that exist today in the context of cloud computing and blockchain
environments and systems.
[0006] As a background, a proxy server acts as a gateway or an
intermediary server separating end users from the websites they
browse. Using a proxy server helps with controlling internet usage
of employees and children, bandwidth savings, improved speeds,
privacy benefits, improved security and access to blocked resources
by pretending to be at another geographical location. Proxy
Re-Encryption is a specialized cryptographic primitive that
facilitates a user to share his encrypted file with another user
without decrypting the file using a specialized key called
Re-Encryption Key (ReKey). Proxy controls which ciphertext of the
user needs to be translated or re-encrypted. There are no
mechanisms known in the industry that allow flexible user control
to proxy reencryption.
[0007] The current model of cloud storage is operated through
centralized authorities, which makes such a system susceptible to
single point failures and permanent loss of data. Blockchain
technology, initially designed as a financial ledger has attracted
the attention of researchers in a wide range of applications
requiring accountable computing and auditability. Blockchain
enabled distributed peer-to-peer cloud storage solutions are
steadily replacing its centralized counterpart. A blockchain
provides multiple parties to agree upon transactions and contracts
in an immutable and auditable way. Decentralized applications such
as dApp providers make use of this capability to provide services
that are transacted in a publicly verifiable manner. When the
service provided by the dApp is not directly from the dApp owner
itself but from other third parties, it brings up additional
challenges. How would the end user using the dApp trust that the
unknown third party service provides used by the dApp are trust
worthy? The current approaches in the industry use a combination of
unencrypted to cumbersome ways.
[0008] While there are policies in the industry that provide
end-to-end user flexibility in securing content from authoring to
distribution, none of them offer flexibility in a blockchain setup
where there is no single entity on the cloud controlling access.
While most systems offer securing content, they may fall short of
providing an independently verifiable audit capability. In a world
of increasing cyber crime and digital fraud, when something goes
wrong, it requires a lot of time and effort to do digital forensic
investigation. Blockchains can help reduce this burden by ensuring
tamper-proof auditability is part of the enterprise workflows.
[0009] While there are means to enable shared smart contracts, a
wallet is typically assigned to a single person or entity. For an
entity hosting a smart wallet, there may be more than one person
who has the access rights to make decisions of spending or buying
on that smart wallet. In such a situation, the entity smart wallet
authentication system is vulnerable if passwords are shared by two
or more people. Such a vulnerability could also exist for a smart
wallet associated with a household that has two or more members
with access privileges.
[0010] Most of the existing and prevalent authentication methods
rely on password-based authentication. Enterprises already use a
single-sign on to make it easy for their employees to login to
their various internal applications that each require login. Some
require changing the password every few weeks or months. Some even
prevent reusing the previous 10 passwords, making it extremely
painful to employees. While this improves the security, it imposes
unnecessary burden on the employees. There is no simple, seamless
and effortless method to provide access without compromising on the
level of security provided. With cybersecurity and privacy laws,
enterprises have a higher need to provide a higher level
security.
SUMMARY OF THE INVENTION
[0011] The present invention is systems and methods on a blockchain
platform for one or more intermediaries comprising: receiving a
ciphertext from a first user with condition parameters that has
been encrypted with a dynamically selected encryption algorithm;
receiving a re-encryption key for a second user from the first
user; identifying whether the ciphertext is valid; re-encrypting
the ciphertext; outputting the re-encrypted ciphertext only if the
ciphertext is valid; and achieving security against chosen
ciphertext attack and distributed denial-of-service attack; sending
the re-encrypted ciphertext to the second user for decryption.
[0012] The system and method for intermediaries, wherein the
intermediary does not have the ability to decrypt the received
ciphertext.
[0013] The system and method for intermediaries, further
comprising: skipping outputting the re-encrypted ciphertext based
on one or more condition parameters.
[0014] The system and method for intermediaries, further
comprising: sending the re-encrypted ciphertext to a second
intermediary for second hop re-encryption.
[0015] A system and method of a blockchain platform for an
intermediary, comprising: receiving an encrypted file from a user
for storage on the blockchain platform; mapping the user to be the
owner of the encrypted file; receiving one or more security policy
parameters for the encrypted file from the owner; enforcing the
security policy parameters for all access requests to the file on
the blockchain platform; and optionally providing audit report of
the encrypted file storage and access.
[0016] The system and method for intermediaries, wherein the owner
is established using past read or write transactions performed
directly on the blockchain platform.
[0017] The system and method for intermediaries, further
comprising: dividing the encrypted file into two or more parts
before sending for storage on the blockchain platform.
[0018] A system and method of a blockchain platform for a smart
wallet, comprising: assigning a total number of two or more
public-private key pairs for users associated with the smart
wallet; allocating a threshold number for approval on transaction
on the smart wallet wherein the threshold number is less than or
equal to the total number; creating a group key from the total
number of public-private keys and the threshold number for
approvals; using the group key to register the smart wallet on the
blockchain; receiving for a transaction a shared signature based on
the group key from two or more users; validating and finalizing the
transaction when the received signatures are more than the
threshold number.
[0019] The system and method of the smart wallet, wherein: the
smart wallet with the group key supports all the functions of a
single user wallet.
[0020] A system and method of blockchain platform for
authenticating clients, comprising of: creating a public and
private key at a client device; splitting the private key into two
or more parts; assigning the split private key part to two or more
client devices; signing to authenticate a challenge using a partial
key part at one of the client devices; sending the challenge to the
remaining client devices who sequentially sign using short range
wireless network connection; responding back to the challenge to
login without a password.
BRIEF DESCRIPTION OF THE DRAWINGS
[0021] The embodiments of this invention are illustrated by way of
example and not limitation in the figures of the accompanying
drawings, in which like references indicate similar elements and in
which:
[0022] FIG. 1 shows a diagram illustrating an example of a system
and method on a blockchain platform with intermediaries, clients
and service providers.
[0023] FIG. 2 shows Table 1 and Table 2. Table 1 discloses
Performance Evaluation of the CPA secure El-Gamal Encryption Scheme
and disclosed Self-Encryption Scheme. Table 2 discloses Performance
Evaluation of the efficient pairing-free unidirectional PRE scheme
due to Chow et al., and disclosed Scheme.
[0024] FIG. 3 is an exploded view of an intermediary computing
system illustrating different modules and functions, according to
one embodiment.
[0025] FIG. 4 discloses an encrypted file access with independent
audit service provider work flow illustrating different modules and
functions, according to one embodiment.
[0026] FIG. 5 discloses messaging work flow to access an encrypted
file and audit reporting on a blockchain platform with server-side
integration, according to one embodiment.
[0027] FIG. 6 discloses messaging work flow to access an encrypted
file and audit reporting on a blockchain platform with server and
client-side integration, according to one embodiment.
[0028] FIG. 7 is a schematic diagram of exemplary computing devices
that can be used to implement the methods and systems disclosed
herein, according to one embodiment.
[0029] FIG. 8 discloses messaging flow for multiple signatures
smart contract implementation, according to one embodiment.
[0030] FIG. 9 discloses messaging flow for multiple signatures
smart wallet implementation, according to one embodiment.
[0031] FIG. 10 discloses messaging flow for password less login
using split-keys, according to one embodiment.
[0032] FIG. 11 is a flow chart showing different method steps in
implementing password less login using split-keys, according to one
embodiment.
DETAILED DESCRIPTION OF THE INVENTION
[0033] The systems and methods on a blockchain platform for
intermediaries and passwordless login allow for intermediary proxy
re-encryption, independent audits, secure multiple persons
controlled smart contract or smart wallet, and split-keys
short-range wireless device-based and passwordless client
authentication. One or more entities (or service providers) that
help or manage the self-regulation on the blockchain platform are
miners. A client is an end-user with two or more computing devices
who initiates the requests and wants to commit transactions on the
blockchain platform. An intermediary may be a blobber or a sharder
who uses a computing device that processes the applications on the
blockchain platform.
[0034] Different embodiments described herein include components or
structures to perform the described functionality. A "component" or
a "module" as used in this invention disclosure, includes a
dedicated or shared processor and, typically, firmware or software
modules executed by the processor. Depending upon
implementation-specific or other considerations, a module can be
centralized or its functionality distributed. A component or a
module can include special purpose hardware, firmware, or software
embodied in a computer-readable medium for execution by the
processor.
[0035] In one embodiment, FIG. 1 depicts a diagram 100 illustrating
an example on a blockchain platform with intermediaries. In the
example of FIG. 1, the environment includes a first consumer or
client system 110-1 through an nth client system 110-n wherein each
client owns two or more devices 1, 2, 3, . . . n, network 140,
intermediary system 120-1 through an nth intermediary system 120-n
and a service provider 130-1 through an nth system 130-n. In an
implementation, the client system 110 includes components related
to requesting services from the blockchain platform. In one
implementation, the client system 110 requests and uses a storage
application for storage, read or write. The client may use a
multiple signatures or group-based smart-contract or smart-wallet
on the blockchain platform. The client may use passwordless
authentication using split keys that are associated with two or
more client devices. The client may request audit reporting for any
of its transactions including storage read/write requests or
adding/deleting of tokens from a smart contract or smart
wallet.
[0036] The intermediary provides enforcement to parameters set with
flexibility by a client including security policies on an encrypted
file owned by a client. The intermediaries operate securely on the
blockchain platform. The clients can delegate reencryption and use
intermediaries as proxies. The intermediary can be providing proxy
services, audit reporting server, enforcing multiple signatures on
a smart contract or a smart wallet, provider of server-side
passwordless authentication.
[0037] The service provides provide the underlying blockchain
platform basic operations functionality. The blockchain platform
may operate on a token-based transaction system. For example, in
one embodiment, the service providers manage tokens when using a
resource on the blockchain or when providing service.
[0038] Network 140 can be different wireless and wired networks
available to connect different computer devices including client
and server systems. In an implementation, network 140 is publicly
accessible on the internet. In an implementation, network 140 is
inside a secure corporate wide area network. In an implementation,
network 140 allows connectivity of different systems and devices
using a computer-readable medium. In an implementation, the
blockchain platform allows users on the client system, the blobber,
the sharder or the miner to have customized applications and
operational framework.
[0039] The messaging and notification between different components
can be implemented using application programming interface (API)
calls, extensible markup language ("XML") interfaces between
different interfaces, Java/C++ object oriented programming or
simple web-based tools. Different components may also implement
authentication and encryption to keep the data and the requests
secure.
I. Sharing of Encrypted Files on Blockchain Using Pre
[0040] The recent explosion of data volumes and demand for
computing resources have prompted individuals and organizations to
outsource their storage and computation needs to online data
centers, such as cloud storage. While data security is enforced by
standard public-key encryption mechanisms in the cloud, secure data
sharing is enabled by efficient cryptographic primitives such as
proxy re-encryption (PRE). PRE enables re-encryption of ciphertexts
from one public key into another via a semi-trusted third party
termed proxy, who does not learn any information about the
underlying plaintext. A user can delegate access to his files by
constructing a special key, termed as re-encryption key, using
which the proxy performs the ciphertext transformation towards a
legitimate delegatee. PRE systems can be classified into
unidirectional and bidirectional schemes based on the direction of
delegation. They can also be classified into single-hop and
multi-hop schemes based on the number of re-encryptions permitted.
In this work, we focus on unidirectional and single-hop PRE
schemes.
[0041] Using dApp called OBox, a storage dApp allows any user to
upload and share their files to their friends and families similar
to many other popular storage services. However, most existing
services trust the service provider and upload the content without
any encryption. But Obox strives to provide zero-knowledge storage
such that the third-party storage providers will not know the
uploaded content. This is achieved using an efficient CCA-secure
proxy re-encryption scheme, outlined in this paper. When a user
shares the encrypted content with a trusted party, he provides the
reencryption keys using the public key of the trusted party so that
only that party is able to decrypt the content. By facilitating the
associated transactions on the blockchain, this scheme provides an
end-to-end transparency and security for end users to procure
storage services at highly competitive prices without worrying
about the reputation of the storage providers. We first propose a
novel self-encryption (SE) scheme, which is much more efficient
than the standard CPA secure El-Gamal encryption scheme. This work
is further extended to design a CCA-secure proxy re-encryption
scheme (SE-PRE) that adds re-encryption functionality to
self-encryption. Our PRE design is much more efficient than the
schemes known in the industry.
[0042] We give the definitions of various assumptions adopted for
proving the security of the proposed schemes, the general and
security model of SE and SE-PRE schemes. (1) Definition 1. Discrete
Logarithm Problem (DLP): The discrete logarithm problem in a cyclic
group G of order q is, given (q; P; Y) such that q is a large
prime, P; Y.di-elect cons. G, find a.di-elect cons.Z*.sub.q such
that Y=aP. (2) Definition 2. Computation Diffie Hellman Problem
(CDH): The Computation Diffie Hellman Problem in a cyclic group G
of order q is, given (q; P; aP; bP) such that q is a large prime,
P; aP; bP.di-elect cons.G, find Q such that Q=abP, where a.di-elect
cons.Z.sup.*.sub.q.
[0043] The self encryption (SE) is a novel primitive that allows a
user to store their files securely with minimal computation
overhead. This primitive is different from the traditional public
key encryption approach as encryption can be done only by the owner
of the file who possess the private key related to the public key
which is used for encrypting the file. It has the following
algorithms: (1) Setup, (2) KeyGen, (3) Self-Encrypt, and (4)
Self-Decrypt. Setup(k) algorithm is run by the trusted entity. On
input of a security parameter k, the Setup algorithm will output
the system parameters Params. KeyGen(Ui, Params) algorithm is run
by the user Ui. This is used to generate a public and private key
pair (PK.sub.i; SK.sub.i) for the user Ui. Self-Encrypt(m, t.sub.w,
SK.sub.i, PK.sub.i, Params) is an encryption algorithm is run only
by the user Ui. This algorithm requires the knowledge of the
private key SK, corresponding to the public key PK.sub.i of user
Ui. This takes as input the message m, the tag t.sub.w, the private
key SK.sub.i and public key PK.sub.i of user Ui. It will output a
ciphertext C which is the encryption of message m under the public
key PK.sub.i and tag t.sub.w. This approach different from the
traditional public key encryption where the encrypt algorithm can
be run by any user. Self-Decrypt(C, SK.sub.i, PK.sub.i, Params):
The decryption algorithm is run by the user U.sub.i. On input of
the ciphertext C, the private key SK.sub.i and the public key
PK.sub.i of user U.sub.i, this will output the message m if C is a
valid self encryption of m under PK.sub.i, SK.sub.i and t.sub.w.
Otherwise, it returns .perp.. In one embodiment, the generic model
of Self Encryption algorithms consists of the algorithms described
in this paragraph.
[0044] The SE-PRE is a proxy re-encryption primitive that uses a
self encryption scheme as the base algorithm and provides a
mechanism to delegate the self-encrypted ciphertext. The SE-PRE
scheme consists of the following algorithms: 1. Setup(k):The setup
algorithm takes as input a security parameter k. This will output
the system parameters Params. This algorithm is run by a trusted
party. 2. KeyGen(Ui, Params): The key generation algorithm
generates a public and private key pair (PK.sub.i; SK.sub.i) of
user Ui. This algorithm is run by a user Ui. 3. ReKeyGen(SK.sub.i;
PK.sub.i; PK.sub.j; c.sub.w; Params): The re-encryption key
generation algorithm takes as input a private key SK.sub.i of
delegator U.sub.i, public key PK.sub.i of delegator U.sub.i, public
key RK.sub.j of delegatee U.sub.j and condition c.sub.w under which
proxy can re-encrypt. It outputs a re-encryption key
RK.sub.i->j. This is executed by the user U.sub.i. 4.
Self-Encrypt(m, t.sub.w, SK.sub.i, PK.sub.i, Params): The self
encryption algorithm takes as input the message m, the tag t.sub.w,
the private key SK.sub.i of user U.sub.i and public key PK.sub.i of
the user U.sub.i. It outputs a ciphertext C which is the encryption
of message m under the public key PK.sub.i, private key SK.sub.i
and tag t.sub.w. This algorithm is executed by the user U.sub.i. 5.
Re-Encrypt(C; PK.sub.i; PK.sub.j; c.sub.w; RK.sub.i->j; Params):
The re-encryption algorithm takes as input a self-encrypted
ciphertext C, the delegator's public key PK.sub.i, the delegatee's
public key PK.sub.j, the condition c.sub.w and a re-encryption key
RK.sub.i->j corresponding to c.sub.w. It outputs a ciphertext D
which is the encryption of same m under public key PK.sub.j of user
U.sub.j. This is run by a proxy who is provided with the
re-encryption key RK.sub.i->j. 6. Self-Decrypt(C, SK.sub.i,
PK.sub.i, Params): The self decryption algorithm is run by the user
U.sub.i. This will take as input the ciphertext C, the private key
SK.sub.i of user U.sub.i and public key PK.sub.i of user U.sub.i.
It will output the message m if C is a valid encryption of m under
PK.sub.i and Sk.sub.i of user U.sub.i and tag t.sub.w. If C is not
valid, this algorithm returns .perp.. 7. Re-Decrypt(D, SK.sub.j,
Params): The re-decryption algorithm takes as input a re-encrypted
ciphertext D and a private key SK.sub.j of user U.sub.j. It outputs
a message m.di-elect cons.M, if D is a valid re-encrypted
ciphertext of message m or the error symbol .perp. if D is invalid.
This algorithm is run by the user U.sub.j. In one embodiment, the
generic model of proxy re-encryption with self-encryption (SE-PRE)
includes algorithms described in this paragraph.
[0045] The security model gives details about the restrictions and
oracle accesses given to the adversary. It is modelled as a game
between a challenger C and an adversary A. The security of
Self-Encryption (SE) scheme against chosen ciphertext attacks
(IND-SE-CCA) is demonstrated as a game between an adversary A and a
challenger C. The game is as follows: (1) Setup: C takes a security
parameter k and runs the Setup(k) algorithm to generate the system
parameters Params. It provides Params to A. C then runs KeyGen(U;
Params) to generate a private and public key pair SK; PK of user U
and provides PK to A. SK is kept by A. (2) Phase-1: A can
adaptively issues queries to the following oracles provided by C:
Self-Encrypt(m; t.sub.w) Oracle: C runs the Self-Encrypt(m,
t.sub.w, SK, PK, Params) algorithm to generate the ciphertext C and
returns it to A. Self-Decrypt(C, PK) Oracle: C runs the
Self-Decrypt(C, SK, PK, Params) and returns the output to A. (3)
Challenge: After getting sufficient training, A submits two
messages m0 and m1 from M of equal length and a tag t.sub.w* to C.
C picks a random bit .delta..di-elect cons.{0; 1} and outputs the
ciphertext C*=Self-Encrypt(m.sub..delta.; t.sub.w*, SK; PK). (4)
Phase-2: On receiving the challenge C*, A is allowed to access the
various oracles provided in Phase-1 with the restrictions given
below: (i). Self-Decrypt(C*) query is not allowed. (ii)
Self-Encrypt(m.sub..delta.; t.sub.w*) query is not allowed.(5)
Guess : After getting sufficient training, A will output its guess
. A wins the game if .delta.=.delta.'. In one embodiment, the
security model for self-encryption includes algorithms described in
this paragraph.
[0046] Security model for the SE-PRE scheme is described below. The
model involves the security of original ciphertext as well as
transformed ciphertext. The ciphertext that can be re-encrypted is
called the original ciphertext and the output of the re-encryption
is called the transformed ciphertext. Security of Original
Ciphertext: The security of Proxy Re-Encryption with
Self-Encryption (SE-PRE) schemes against chosen ciphertext attacks
(IND-SE-PRE-CCAO) for the original ciphertext is modelled as a game
between an adversary A and a challenger C. The security game is
described below: (1) Setup: C takes a security parameter k and runs
the Setup(k) algorithm to generate the system parameters Params.
The Params is then given to A. (2) Phase-1: On receiving the system
parameters, a target public key PK.sub.T and tag t.sub.w*, A is
allowed to access Keygen, Self-Encrypt, Self-Decrypt, Rekey,
Re-Encrypt, Re-Decrypt algorithms. A simulates the algorithms as
oracles and A can adaptively issue queries to these oracles. The
various oracles provided by C are: (a) Corrupted KeyGen(U.sub.i): C
runs the KeyGen(U.sub.i; Params) to obtain the public and private
key pair (PK.sub.i; SK.sub.i). C returns both SK.sub.i and PK.sub.i
to A. (b) Uncorrupted KeyGen(U.sub.i): C runs the KeyGen(U.sub.i;
Params) to obtain the public and private key pair (PK.sub.i;
SK.sub.i) and returns PK.sub.i to A. SK.sub.i is not provided to A.
(c) ReKeyGen(U.sub.i; U.sub.j): C runs the ReKeyGen(SK.sub.i;
PK.sub.i; PK.sub.j; c.sub.w; Params) to obtain the re-encryption
key RK.sub.i!.sub.j and returns it to A. (d) Self-Encrypt(m;
t.sub.w; PK.sub.i) : C runs the Self Encrypt(m, t.sub.w, SK.sub.i,
PK.sub.i, Params) to obtain the ciphertext C and returns it to A.
(e) Re-Encrypt(C, PK.sub.i, PK.sub.j, c.sub.w): C runs the
Re-Encrypt(C; PK.sub.i; c.sub.w; RK.sub.i!.sub.j; Params) to obtain
the ciphertext D and returns it to A. Here, RK.sub.i!.sub.j is the
re-encryption key from PK.sub.i to PK.sub.j under the condition
c.sub.w. (f) Self-Decrypt(C, PK.sub.i): C runs the Self-Decrypt(C,
SK.sub.i, PK.sub.i, Params) and returns the output to A. (g)
Re-Decrypt(D, PK.sub.j): C runs the Re-Decrypt(D, SK.sub.j,
PK.sub.j, Params) and returns the output to A. For the ReKey,
Encrypt, Re-Encrypt, Decrypt, Re-Decrypt oracle queries it is
required that public keys PK.sub.i and PK.sub.j are generated
beforehand. (3) Challenge : On getting sufficient training, A will
output two equal-length plaintexts m0 , m1 2 M. Here, the
constraint is: PK.sub.T is generated using Uncorrupted Keygen and
Rekey(PK.sub.T, PK.sub.j, c.sub.w); is not queried in Phase-1 for
c.sub.w=t.sub.w*C flips a random coinf0; 1 g, and sets the
challenge ciphertext C*=Self-Encrypt(m, t.sub.w*, SK.sub.T,
PK.sub.T, Params). C then provide C* as challenge to A. (4)
Phase-2: A can adaptively query as in Phase-1 with the following
restrictions: 1. A cannot issue Corrupted KeyGen(U.sub.T) query. 2.
A cannot issue Self-Decrypt(C*, PKT, t.sub.w*) query. 3. A cannot
issue Re-Encrypt(C*, PK.sub.T; PK.sub.j) query on C* from PK.sub.T
to PK.sub.j if PK.sub.j is Corrupted. 4. A cannot issue
ReKey(PK.sub.T, PK.sub.j; c.sub.w) query if c.sub.w=t.sub.w*. 5. A
cannot issue Re-Decrypt query on D*; PK.sub.j if D* is the output
of Re-Encrypt(C*, PK.sub.T, PK.sub.j, c.sub.w) and c.sub.w=t.sub.w*
(5) Guess : Finally, A outputs a guess .delta..di-elect cons.{0; 1}
and wins the game if .delta.'=.delta..
[0047] The security of transformed of Proxy Re-Encryption with
Self-Encryption(SE-PRE) scheme against chosen ciphertext
attacks(IND-SE-PRE-CCAT) is modelled as a game between an adversary
A and a challenger C. This is achieved by: (1) Setup: C takes a
security parameter k and runs the Setup(k) algorithm and gives the
resulting system parameters Params, a target public key PK.sub.T
and tag t.sub.w* to A. (2) Phase-1: This phase is similar to the
Phase-1 of IND-SE-PRE-CCA.sub.O. We do not provide Re-Encrypt
oracle as we are providing all the re-encryption keys for the
adversary. (3) Challenge: Once A decides Phase-1 is over, it
outputs two equal-length plaintexts m.sub.0, m.sub.1.di-elect
cons.M. C flips a random coin .delta. {0; 1}, and sets the
challenge ciphertext as follows: (a) Compute C*=Self-Encrypt(m,
t.sub.w*, SK.sub.i, PK.sub.i, Params), (PK.sub.i; SK.sub.i be the
public, private key pair of user U.sub.i and U.sub.i can be honest
or corrupt. (b) Sets D*=Re-Encrypt(C*; RK.sub.i->T) which is
then sent to A. (3) Phase-2: A adaptively issues queries as in
Phase-1, and C answers them as before with the following
restrictions: (i). A cannot issue Corrupted KeyGen(U.sub.T) query.
(ii) A cannot issue Re-Decrypt(D*; PK.sub.T) query. (4) Guess:
Finally, A outputs a guess .delta.'.di-elect cons.{0; 1} and wins
the game if .delta.'=.delta..
[0048] Self-Encrypt scheme is a special kind of encryption
primitive that allows a user to store file securely in cloud or any
distributed storage. In this approach the owner of the file uses
his/her private key to encrypt the file. This significantly reduces
the computation involved in storing the file. We provide the self
encryption scheme and the prove its CCA security in the random
oracle model.
[0049] The SE scheme consist of the following algorithms: (1)
Setup(K): Let G be an additive cyclic group of prime order q. Let P
be a generator of group G. Let .DELTA.=Sym.Encrypt, Sym.Decrypt be
any symmetric key encryption scheme. We may assume that .DELTA. is
a symmetric key encryption algorithm that uses messages of block
size k. Choose the hash functions, [0050] H.sub.1: {0,
1}.sup.l.sup.t.times.Z.sub.q*.fwdarw.Z.sub.q* [0051] H.sub.2:
Z.sub.q*.fwdarw.{0, 1}.sup.l.sup.k [0052] H.sub.3: {0,
1}.sup.l.sup.m.times.G.fwdarw.{0, 1}.sup.l.sup.3
[0053] Here l.sub.t is the size of the tag, l.sub.m is the size of
the message and l.sub.k is the size of the symmetric key used by
the symmetric key encryption scheme .DELTA.. Also, l.sub.3 is
dependent on the security parameter .kappa.. Output Params=(q; G;
P; H.sub.1( ); H.sub.2( ); H.sub.3( ), .DELTA.). KeyGen(U, Params):
The KeyGen algorithm generates the public and private key of the
user U by performing the following steps: (i) Choose a random
integer x.rarw.R.sub.q* (ii) Output PK={X=Xp} and SK=<x>.
Self-Encrypt(m, t.sub.w, SK, PK, Params): On input of message m,
tag t.sub.w, private key SK=x of user U, public key PK=xP of user U
and the public parameters Params this algorithm will generate the
self encryption as follows: [0054] Choose random t.di-elect
cons..sub.q* [0055] Set h.sub.1=H.sub.1(t.sub.w, x), [0056] Set
C.sub.1=t+h.sub.t, [0057] Compute Key=H.sub.2(t) [0058]
C.sub.2={C.sub.i}.sub.(for i=1 to l) and C.sub.i=Sym.Encrypt
(M.sub.i, Key) for all i=1 to l, l is the number of blocks. Assume
that m=M.sub.1 M.sub.2 . . . M.sub.l where |M.sub.i|=k and k is the
block size of .DELTA., [0059] C.sub.3=H.sub.3(m, t) [0060] Output
the ciphertext C=(C.sub.1, C.sub.2, C.sub.3, t.sub.w).
[0061] Self-Decrypt(C, SK.sub.i, Params): Self decryption algorithm
is used to decrypt the files that are previously encrypted by the
user U using his/her private key. This algorithm does the
following: [0062] h.sub.t=H.sub.1(t.sub.w, SK.sub.i), [0063]
t=C.sub.1-h.sub.t [0064] Key=H.sub.2(t) [0065] Compute
M.sub.i=Sym.Decrypt(C.sub.i, Key) for all i=1 to l and construct
m=M.sub.1 M.sub.2 . . . M.sub.l, [0066] If C.sub.3H.sub.3(m, t)
then, output m. Else, Output .perp..
Correctness of t
[0067] RHS = C 1 - h t = ( t + h t ) - h t = t ; = LHS
##EQU00001##
[0068] The Security Proof can be given as follows: [0069] Theorem
1. If there exist a (.gamma., ) adversary with an advantage that
can break the IND-SE-CCA security of the SE scheme, then C can
solve the discrete log problem with advantage ' where,
'.gtoreq.
[0070] Proof: In this section we formally prove the security of SE
scheme in the random oracle model. The IND-SE-CCA security of the
SE scheme is reduced to the discrete logarithm problem(DLP). The
challenger A is given with the instance of DLP (i.e. given (q, P,
Y) such that q is a large prime, P, Y.di-elect cons.G, find a such
that Y=ap.) If there exist an adversary A that can break the
IND-SE-CCA security of the SE scheme, then C can make use of A to
solve the discrete logarithm problem, which is assumed to be hard.
Thus the existence of such adversary is not possible.
[0071] The challenger C sets the public key PK=Y (PK=aP) and the
corresponding private key SK=x=a (which is not know to C). C then
provides PK to A. A then has access to various algorithms of SE and
the hash functions as oracles. C simulates the hash functions and
the Self-Encrypt, Self-Decrypt algorithms as described below.
[0072] Phase-1: is given to access all the oracles as defined in
the security model IND-SE-CCA. Here it should be noted that C which
does not have the knowledge of private key SK=.alpha. provides the
functionalities Self-Encrypt, Self-Decrypt algorithm. [0073] The
hash functions involved in the SE scheme are simulated as random
oracles. To provide consistent output, C maintains the lists
L.sub.H.sub.1, L.sub.H.sub.2 and L.sub.H.sub.3 corresponding to the
hash function H.sub.1, H.sub.2 and H.sub.3 involved in the SE
scheme. [0074] H.sub.1 Oracle: When a query with input (t.sub.w, x)
is made, the tuple (t.sub.w, x, h.sub.t) is retrieved from
L.sub.H.sub.1 and h.sub.t is returned, if (t.sub.w, x) is already
there in L.sub.H.sub.1 list. Otherwise, C does the following:
[0075] If xP=Y, then abort. This is because C obtains the solution
to DLP i.e. x=.alpha.. [0076] Pick h.sub.1.di-elect cons. [0077] If
h.sub.t is already present in L.sub.H.sub.1 list, go to previous
step. [0078] Store (t.sub.w, x, h.sub.t) in L.sub.H.sub.1 list and
output h.sub.t. [0079] H.sub.2 Oracle: When a query with t is made,
C the tuple (t, Key) from LH.sub.2 list is retrieved and will
return Key, if (t) is already present in L.sub.H.sub.2 list.
Otherwise, C does the following: [0080] Pick Key.di-elect cons.{0,
1}.sup.l.sup.k. [0081] If Key is already present in L.sub.H.sub.2
list, go to previous step. [0082] Store (t, Key) in L.sub.H.sub.2
list and return Key. [0083] H.sub.3 Oracle: When a query with input
(m, T) is made, C retrieves the tuple (m, T, .alpha.) from
L.sub.H.sub.3 list and returns .alpha., if (m, T) is already
present in L.sub.H.sub.3 list. Otherwise, C does the following:
[0084] Pick .alpha..di-elect cons.{0, 1}.sup.l.sup.3, [0085] If
.alpha. is already present in L.sub.H.sub.3 list, go to previous
step. [0086] Store (m, T, .alpha.) in L.sub.H.sub.3 list and return
.alpha..
[0087] The Self-Encrypt and Self-Decrypt as well as Challenge
Phase, Phase-2 and Guess, according to one embodiment, can be
described as follows: [0088] Self-Encrypt Oracle: When a
Self-Encrypt query is made with (m, t.sub.w) as input, C does the
following: [0089] Choose random t.di-elect cons..sub.q* [0090] Set
h.sub.l=H.sub.1 (t.sub.w, x), [0091] Set C.sub.1=t+h.sub.1. [0092]
Compute Key=H.sub.2(t) [0093] C.sub.2={C.sub.i}.sub.(for i=1 to l)
and C.sub.i=Sym.Encrypt (M.sub.i, Key) for all i=1 to l, l is the
number of blocks, Assume that m=M.sub.1 M.sub.2 . . . M.sub.l where
|M.sub.i|=k and k is the block size of .DELTA.. [0094]
C.sub.3=H.sub.3(m, t) [0095] Output the ciphertext C=(C.sub.1,
C.sub.2, C.sub.3, t.sub.w). [0096] Output the self-encrypted
ciphertext C to . [0097] Self-Decrypt Oracle: When a Self-Decrypt
query is made with C=(C.sub.1, C.sub.2, C.sub.3, t.sub.w) as input,
C performs the following: [0098] If C is in L.sub.Encrypt list,
pick m corresponding to C from the tuple (C, m) in L.sub.Encrypt
list and output m. [0099] If (t.sub.w, . . . ) is present in
L.sub.H.sub.1 list then, retrieve h.sub.l corresponding to
(t.sub.w, . . . ) from L.sub.H.sub.1 list. Else, it returns .perp.
[0100] T=C.sub.1-ht [0101] Key=H.sub.2(t) [0102] Compute
M.sub.i=Sym.Decrypt (C.sub.i, Key) for all i=1 to l and construct
m=M.sub.1 M.sub.2 . . . M.sub.l. [0103] If C.sub.3H.sub.3(m, t)
then, output m. Else it output .perp. [0104] Challenge Phase: After
the first phase of training is over, provides m.sub.0,
m.sub.1.di-elect cons., t.sub.w* such that (m.sub.0, t.sub.w*) or
(m.sub.1, t.sub.w*) was not queried to Self-Encrypt oracle during
Phase-1 and provides to C. C now generates the challenge ciphertext
C*=Self-Encrypt(m.sub..delta., t.sub.w*) and .delta..di-elect
cons..sub.R {0, 1} [0105] Phase-2: can interact with all the
oracles as in Phase-1 but with the following restrictions, [0106]
cannot make the query Self-Decrypt(C*) [0107] cannot make the query
Self-Encrypt(m.sub..delta., t.sub.w*), .delta..di-elect cons.{0, 1}
[0108] Guess: Once Phase-2 is over, output its guess .delta.'. wins
the game if .delta.=.delta.'.
[0109] In one embodiment, the proxy re-encryption with
self-encryption scheme is described as follows. The SE scheme is
modified such a way that it allows verifiability of ciphertext by
proxy during re-encryption without knowing the message. It helps in
achieving CCA security of SE-PRE. This also helps in avoiding the
DDOS attack being launched on Proxy's service. The proxy is
equipped with a method to identify invalid ciphertext so that it
will serve its functionality only to valid input. Also, the SE-PRE
algorithm can be deployed in a simple and efficient manner than
using the traditional PRE schemes available till date. In one
embodiment, the SE-PRE uses private encryption algorithm.
[0110] The setup algorithm is described as follows: [0111]
Setup(k): [0112] Let be an additive cyclic group of prime order q.
Let P be a generator of group . [0113] Let .DELTA.={Sym.Encrypt,
Sym.Decrypt} be any symmetric key encryption scheme. We may assume
that .DELTA. is a symmetric encryption algorithm working on block
of size k. [0114] Choose the has functions, [0115] H.sub.0: {0,
1}.sup.l.sup.t.fwdarw.{0, 1}.sup.l.sup.0 [0116] H.sub.1: {0,
1}.sup.l.sup.t.times..sub.q*.times..fwdarw..sub.q* [0117] H.sub.2:
.sub.q*.fwdarw.{0, 1}.sup.l.sup.k [0118] H.sub.3: {0,
1}.sup.l.sup.m.times..sub.q*.fwdarw.{0, 1}.sup.l.sup.a [0119]
H.sub.4: .sub.q*.times.{0,
1}.sup.(l.sup.a.sup.+l.sup.0.sup.+l.sup.o.sup.).times..fwdarw..sub.q*
[0120] H.sub.5: {0, 1}.sup.l.sup.t.times..sub.q*.times..fwdarw.{0,
1}.sup.l.sup.o [0121] H.sub.6: {0,
1}.sup.l.sup.w.times..times..times..fwdarw..sub.q* [0122] H.sub.7:
.sub.q*.times..fwdarw..sub.q* [0123] H.sub.8: .times..fwdarw.{0,
1}.sup.(l.sup.w.sup.+l.sup.y.sup.) [0124] H.sup.9: {0,
1}.sup.l.sup.u.times..sub.q*.fwdarw..sub.q* [0125] H.sub.10: {0,
1}*.fwdarw.{0, 1}.sup.l.sup.c [0126] Here l.sub.t is size of the
tag, l.sub.m is size of the message, l.sub.c is the size of the
ciphertext, l.sub.p is .kappa. and l.sub.k is size of the symmetric
key used in the encryption scheme .DELTA.. Also, l.sub.w, l.sub.u,
l.sub.O, l.sub.3 and l.sub.5 are dependent on the security
parameter .kappa.. Output Params={q, P, G, P, H.sub.i( ) .sub.(for
i=0 to 9), H.sub.c( ), .DELTA.}
[0127] The KeyGen and RekeyGen can be described as follows: [0128]
KeyGen(U.sub.i, Params): The KeyGen algorithm generates the public
and private key of the user U.sub.i by performing the following:
[0129] Choose a random integer x.sub.i .sub.q* [0130] Output
PK.sub.i=(X.sub.i=x.sub.iP) and SK=(x.sub.i).
[0131] RekeyGen(SK.sub.i, PK.sub.i, PK.sub.j, c.sub.w, Params):
This algorithm generates the re-encryption key required to
translate a ciphertext of user U.sub.i into a ciphertext of user
U.sub.j. This is run by the user U.sub.i. The ciphertext to be
re-encrypted is encrypted under the public key PK.sub.i of user
U.sub.i and with the condition c.sub.w, which are specified by user
U.sub.i. This algorithm works as follows: [0132] Choose
.omega..di-elect cons.{0, 1}.sup.t.sup.w [0133] Compute
h.sub.c=H.sub.1(c.sub.w, x.sub.i, X.sub.i).di-elect cons..sub.q*
[0134] Compute r=H.sub.6(.omega., x, X.sub.j, X.sub.i,
X.sub.j).di-elect cons..sub.q* [0135] Compute s=H.sub.7(r,
X.sub.j).di-elect cons..sub.q* [0136] Compute .gamma.=rX.sub.j
[0137] Compute the re-encryption key RK.sub.i.fwdarw.j={R.sub.1,
R.sub.2, R.sub.3, R.sub.4, R.sub.5, R.sub.6} where, [0138]
R.sub.1=-h.sub.c.di-elect cons..sub.q* [0139] R.sub.2=rP.di-elect
cons. [0140]
R.sub.3=(.omega..parallel.X.sub.i).sym.H.sub.8(.gamma.,
X.sub.j).di-elect cons.{0,1}.sup.l.sup.w.sup..fwdarw.l.sup.g [0141]
R.sub.4=H.sub.6(.omega., .gamma., X.sub.i, X.sub.j).di-elect
cons..sub.q* [0142] R.sub.5=H.sub.5(t.sub.w, x.sub.i,
X.sub.i).di-elect cons.{0,1}.sup.l.sup.5 [0143]
R.sub.6=H.sub.0(t.sub.w) [0144] Output the re-encryption key
RK.sub.i.fwdarw.j=(R.sub.1, R.sub.2, R.sub.3, R.sub.4, R.sub.5,
R.sub.6)
[0145] Self-Encrypt(m, tw, SKi, PKi, Params): On input of message
m, tag tw, private key SKi, public key PKi of user Ui and the
public parameters Params [0146] Choose random .omega..di-elect
cons..sub.q* [0147] Set h.sub.t=H.sub.1(t.sub.w, x.sub.i,
X.sub.i).di-elect cons..sub.q* [0148] Compute C.sub.1=t+h.sub.t.
[0149] Compute Key=H.sub.2(t) [0150] Compute
C.sub.2={C.sub.i}.sub.(for i=t to l) and C.sub.i=Sym.Encrypt
(M.sub.i, Key) for all i=1 to l, l is the number of blocks. Assume
that m=M.sub.1 M.sub.2 . . . M.sub.l where |M.sub.i|=k and k is the
block size of .DELTA.. [0151] Set C.sub.3=H.sub.3(m, t) [0152] Find
.alpha.=H.sub.5(t.sub.w, x.sub.i, X.sub.i).di-elect cons.{0,
1}.sup.l.sup.5 [0153] C.sub.4=H.sub.4(C.sub.1, C.sub.2, C.sub.3,
.alpha., X) [0154] Set C.sub.5=H.sub.0(t.sub.w) [0155] Output the
ciphertext C={C.sub.1, H.sub.t(C.sub.2), C.sub.3, C.sub.4,
C.sub.5)}.
[0156] Re-Encrypt(C, PK.sub.i, PK.sub.j, c.sub.w,
RK.sub.i.fwdarw.j, Params): This algorithm is run by the proxy
which is given with the re-encryption key RK.sub.i.fwdarw.j by user
U.sub.i. This generates the re-encryption of a ciphertext encrypted
under public key PK.sub.i of user U.sub.i under the condition
c.sub.w into a ciphertext encrypted under public key PK.sub.j of
user U.sub.j. This algorithm does not perform any complex
computation and this greatly reduces the computational overhead on
the entity that performs the role of a proxy. This algorithm does
the following computations [0157] If C.sub.4.noteq.H.sub.4
(C.sub.1, H.sub.c(C.sub.2), C.sub.3, R.sub.5, t.sub.w, X) OR
C.sub.5.noteq.R.sub.6, then it returns 195 [0158] Set
D.sub.2=C.sub.2, D.sub.3=C.sub.3, D.sub.4=R.sub.2, D.sub.5=R.sub.3
[0159] Choose .mu..di-elect cons.{0, 1}.sup.l.sup.a [0160] Compute
.beta.=H.sub.9(.mu., R.sub.4).di-elect cons..sub.q* [0161] Compute
D.sub.1=.beta.(C.sub.1+R.sub.1).di-elect cons..sub.q* [0162] Set
D.sub.6=.mu. [0163] Output the re-encrypted ciphertext D=(D.sub.1,
D.sub.2, D.sub.3, D.sub.4, D.sub.5, D.sub.6)
[0164] Self-Decrypt(C, SK.sub.i, Params): Self-Decrypt algorithm is
used to decrypt the self-encrypted ciphertext C of a user that is
stored by him in the cloud. This algorithm performs the following:
[0165] Find .alpha.=H.sub.5(t.sub.w, x.sub.i, X.sub.i).di-elect
cons.{0, 1}.sup.l.sup.s [0166] If C.sub.i.noteq.H.sub.4(C.sub.1,
C.sub.2, C.sub.3, .alpha., t.sub.w, X), then it returns .perp.
[0167] h.sub.t=H.sub.1(t.sub.wSK.sub.i). [0168] t=C.sub.1-h.sub.t
[0169] Key=H.sub.2(t) [0170] Compute M.sub.i=Sym.Decrypt(C.sub.i,
Key) for i=1 to l and construct m=M.sub.1 M.sub.2 . . . M.sub.l.
[0171] If C.sub.3H.sub.3(m, t) then, output m. Else, Output
.perp.
Correctness of t
[0172] RHS = C 1 - h t = ( t + h t ) - h t = t = LHS
##EQU00002##
[0173] Re-Decrypt(D, SK.sub.j, Params): The Re-Decrypt algorithm is
used to decrypt the re-encrypted ciphertext D. This algorithm does
the following: [0174] Compute .gamma.=x.sub.jD.sub.4 [0175] Compute
.omega..parallel.X.sub.i=D.sub.5.sym.H.sub.8 (.gamma., X.sub.j)
[0176] Compute r=H.sub.6 (.omega., x.sub.j, X.sub.i, X.sub.i,
X.sub.j).di-elect cons..sub.q* [0177] Compute s=H.sub.7(r,
X.sub.j).di-elect cons..sub.q* [0178] .rho.=H.sub.5(.omega.,
.gamma., X.sub.i, X.sub.j).di-elect cons..sub.q* [0179] Compute
.beta.=H.sub.9(D.sub.6, .rho.).di-elect cons..sub.q* [0180] Compute
t=.beta..sup.-1(D.sub.1) . . . s [0181] Find Key=H.sub.2(t) [0182]
Compute M.sub.i=Sym.Decrypt(C.sub.i, Key) for all i=1 to l and
construct m=M.sub.1 M.sub.2 . . . M.sub.l. [0183] If
(C.sub.3H.sub.3(m, t)) then, output m. Else, it returns .perp..
[0184] A similar Correctness algorithm can be applied, in one
embodiment, for example, as described below:
Correctness of T
[0185] RHS = .beta. - 1 .times. D 1 - s = .beta. - 1 [ .beta.
.function. ( C 1 + R 1 ) ] - s = [ ( t + h t ) + ( s - h c ) ] - s
t ' ; Here .times. h t = h c = ( t + s ) - s = t = LHS
##EQU00003##
[0186] The Security Proof of the SE-PRE model can be given as
below. The original ciphertext and the transformed ciphertext
security in the random oracle model are consistent.
Security of the Original Ciphertext
[0187] Theorem 2. If a (.gamma., ) adversary with an advantage
breaks the IND-SE-PRE-CCA.sub.O security of the SE-PRE scheme in
time .gamma., then C can solve the discrete log problem or CDH with
advantage ' where,
' .gtoreq. 1 q t .times. ##EQU00004##
[0188] Here, q.sub.t is the number of queries to H.sub.6
oracle.
[0189] Proof: We formally prove the original ciphertext security
IND-SE-PRE-CCA.sub.O of SE-PRE scheme in the random oracle model.
The IND-SE-PRE-CCA.sub.O security of the SE-PRE scheme is reduced
to the discrete algorithm problem(DLP) or the Computational Diffie
Hellman Problem(CDH). The challenger is given with the instance of
CDH q, P, Y=.alpha.P, Y.sup.I=.alpha..sup.2P, Z=bP) such that q is
a large prime, P, Y, Y', Z G. Now, we show that if there exists an
adversary A that can break IND-SE-PRE-CCA.sub.O security of the
SE-PRE scheme then C can make use of that adversary A to solve the
discrete logarithm problem or the CDH problem, which are assumed to
be hard. Hence the existence of such an adversary A is not
possible. Now, adversary A is provided the access to various
Self-Encrypt, Self-Decrypt, ReKey, Re-Encrypt, Re-Decrypt
algorithms and the hash function as oracles. C provides PK.sub.T=Y
AND t.sub.w* to A. The game is demonstrated below.
[0190] Phase-1. interacts with C adhering to the restrictions given
in the security model IND-SE-PRE-CCA.sub.O. submits the target
condition t.sub.w* to C. C answers the queries made to various
Corrupted KeyGen, Uncorrupted Keygen, Self-Encrypt, Self-Decrypt,
ReKey, Re-Encrypt, Re-Decrypt oracles and the hash oracles as given
below: [0191] The hash functions are modelled as random oracles. In
order to provide consistent output, C maintains various lists
L.sub.H.sub.c and L.sub.H.sub.i (for i=0 to 9) corresponding to the
hash functions H.sub.c and H.sub.i, (for i=0 to 9). Oracles
H.sub.1, H.sub.2 and H.sub.3 are simulated as given in the proof of
SE scheme. The other hash oracles are simulated as follows: [0192]
H.sub.0 Oracle: On input of t.sub.w, C checks whether a tuple
(t.sub.w, h.sub.0) corresponding to t.sub.w is there in
L.sub.H.sub.0 list. If it is already present then return h.sub.0,
else pick h.sub.0.di-elect cons.{0, 1}.sup.l.sup.0. Store (t.sub.w,
h.sub.0) in L.sub.H.sub.0 list and return h.sub.0. [0193] H.sub.c
Oracle: On input of {umlaut over (C)}, C checks whether a tuple
({umlaut over (C)}, h.sub.c) corresponding to {umlaut over (C)} is
already there in L.sub.H.sub.c list. If it is present then h.sub.c
is returned, else pick h.sub.c.di-elect cons.{0, 1}.sup.l.sup.c.
Store ({umlaut over (C)}, h.sub.c) in L.sub.H.sub.c list and return
h.sub.c. [0194] H.sub.1 Oracle: When a query with input (t.sub.w,
x, X) is made, the tuple (t.sub.w, x, X h.sub.t) is retrieved from
L.sub.H.sub.t and h.sub.t is returned, if (t.sub.w, x, X) is
already there in L.sub.H.sub.1 list. Otherwise, C does the
following: [0195] If X=X.sub.i in L.sub.Honest and {umlaut over
(x)}.sub.iY=X, then abort. This is because C obtains the solution
to DLP i.e. {umlaut over (x)}.sub.i.sup.-1 x=.alpha.. [0196] Pick
h.sub.t.di-elect cons.. [0197] If h.sub.t is already present in
L.sub.H.sub.t list, go to previous step. [0198] Store (t.sub.w, x,
X, h.sub.t) in L.sub.H.sub.t list and output h.sub.t. [0199]
H.sub.4 Oracle: When H.sub.4 oracle is queried with (C.sub.1,
C.sub.2, C.sub.3, .alpha., t.sub.w) as input, C retrieves the tuple
(C.sub.1, C.sub.2, C.sub.3, C.sub.4, t.sub.w, h.sub.4) from
L.sub.H.sub.4 list and returns h.sub.4, if an entry corresponding
to (C.sub.1, C.sub.2, C.sub.3, .alpha., t.sub.w) is already there
in L.sub.H.sub.4 list. Otherwise, C does the following: [0200] Pick
h.sub.4.di-elect cons..sub.q*. [0201] If h.sub.4 is already present
in L.sub.H.sub.4 list, go to previous step. [0202] Store (C.sub.1,
C.sub.2, C.sub.3, .alpha., t.sub.w, h.sub.4) in L.sub.H.sub.4 list
and return h.sub.4. [0203] H.sub.5 Oracle: When H.sub.5 oracle is
queried with (t.sub.w, x, X) as input, C retrieves the tuple
(t.sub.w, x, X, h.sub.5) from L.sub.H.sub.5 list and returns,
.beta., if an entry corresponding to (t.sub.w, x, X) is already
there in L.sub.H.sub.5 list. Otherwise, C does the following:
[0204] Pick h.sub.5.di-elect cons..sub.q*. [0205] If h.sub.5 is
already present in L.sub.H.sub.5 list, go to previous step. [0206]
Store (t.sub.w, x, X, h.sub.5) in L.sub.H.sub.5 list and return
h.sub.5. [0207] H.sub.6 Oracle: When H.sub.6 oracle is queried with
(.omega., .gamma., X, Y) as input, C retrieves the tuple (.omega.,
.gamma., X, Y, h.sub.6) from L.sub.H.sub.6 list and returns
h.sub.6, if an entry corresponding to (.omega., .gamma., X) is
there in L.sub.H.sub.6 list. Otherwise, C does the following:
[0208] Pick h.sub.6.di-elect cons..sub.q*. [0209] If h.sub.6 is
already present in L.sub.H.sub.6 list, go to previous step. [0210]
Store (.omega., .gamma., X, Y, h.sub.6) in L.sub.H.sub.6 list and
return h.sub.6.
[0211] In one embodiment, H.sub.7 Oracle, H.sub.8 Oracle, H.sub.9
Oracle can be described, for example, as below. A person of
ordinary skill in the art would understand the results are
consistent. [0212] H.sub.7 Oracle: When H.sub.7 oracle is queried
with (r, X) as input, C retrieves the tuple (r, X, h.sub.7) from
L.sub.H.sub.7 list and returns h.sub.7, if an entry corresponding
to (r, X) is already there in L.sub.H.sub.7 list. Otherwise, C does
the following: [0213] Pick h.sub.7.di-elect cons..sub.q*. [0214] If
h.sub.7 is already present in L.sub.H.sub.7 list, go to previous
step. [0215] Store (r, X, h.sub.7) in L.sub.H.sub.7 list and return
h.sub.7. [0216] H.sub.8 Oracle: When H.sub.8 oracle is queried with
(.gamma., X) as input, C retrieves the tuple (.gamma., X, h.sub.8)
from L.sub.H.sub.8 list and returns h.sub.8, if an entry
corresponding to (.gamma., X) is already there in L.sub.H.sub.8
list.. Otherwise, C does the following: [0217] Pick
h.sub.8.di-elect cons.{0, 1}.sup.l.sup.m.sup.+l.sup.p. [0218] If
h.sub.8 is already present in L.sub.H.sub.8 list, go to previous
step. [0219] Store (.gamma., X, h.sub.8) in L.sub.H.sub.8 list and
return h.sub.8. [0220] H.sub.9 Oracle: When H.sub.9 oracle is
queried with (u, r) as input, C retrieves the tuple (u, r, h.sub.9)
from L.sub.H.sub.9 list and returns h.sub.9, if an entry
corresponding to (u, r) is already there in L.sub.H.sub.9 list.
Otherwise, C does the following: [0221] Pick h.sub.9.di-elect
cons..sub.q*. [0222] If h.sub.9 is already present in L.sub.H.sub.9
list, go to previous step. [0223] Store (u, r, h.sub.9) in
L.sub.H.sub.9 list and return h.sub.9. [0224] Corrupted KeyGen
Oracle: When a query is made with input U.sub.i, the C performs the
following: [0225] Picks a random x.sub.i.di-elect cons..sub.q*.
[0226] Computes X.sub.i=x.sub.iP [0227] Sets PK.sub.i=(X.sub.i) and
SK.sub.i=(x.sub.i). [0228] Stores (U.sub.i, x.sub.i, X.sub.i) in
L.sub.Corrupt list and returns (SK.sub.i, PK.sub.i). Here C knows
the private key SK.sub.i of user U.sub.i. [0229] Uncorrupted Keygen
Oracle: When a query is made with input U.sub.i, the C performs the
following: [0230] Picks a random {umlaut over (x)}.sub.i.di-elect
cons..sub.q*. [0231] Computes X.sub.i={umlaut over
(x)}.sub.iY={umlaut over (x)}.sub.i.alpha.P=x.sub.iP, where
x.sub.i={umlaut over (x)}.sub.i.alpha. [0232] Sets
PK.sub.i=(X.sub.i). By definition SK.sub.i=(x.sub.i={umlaut over
(x)}.sub.i.alpha.). This is not known to C; .alpha. is the discrete
log corresponding to Y in the DLP which is given as the challenge
to C. [0233] Stores (U.sub.i, . . . , {umlaut over (x)}.sub.i,
X.sub.i) in L.sub.Honest list and returns PK.sub.i.
[0234] RekeyGen Oracle, in one embodiment, can be described as
follows. On input of (c.sub.w, PK.sub.i, PKj), C does the following
to generate the re-encryption key. [0235] If (PK.sub.i.di-elect
cons.L.sub.Corrupt) [0236] Compute
RK.sub.i.fwdarw.j=RekeyGen(c.sub.w, SK.sub.i, PK.sub.i, PK.sub.j).
[0237] Store (t.sub.w, PK.sub.i, PK.sub.j, RK.sub.i.fwdarw.j) in
L.sub.ReKey list. [0238] Output RK.sub.i.fwdarw.j [0239] If
t.sub.w, PK.sub.i, PK.sub.j has an entry in L.sub.ReKey list,
retrieve and return RK.sub.i.fwdarw.j [0240] If PK.sub.i.di-elect
cons.L.sub.Honest, then [0241] Choose .omega..di-elect cons.{0,
1}.sup.l.sup.w [0242] Choose h.sub.c in .di-elect cons..sub.q* and
store (c.sub.w, . . . , X.sub.i) in L.sub.H.sub.1 list. [0243] If
X.sub.j is corrupt r=H.sub.6 (.omega., {umlaut over
(x)}.sub.ix.sub.j.alpha.P, X.sub.i, X.sub.j).di-elect cons..sub.q*
[0244] If t.sub.w=t.sub.w* and PK.sub.i=PK.sub.T then set
rb=H.sub.6 (.omega., {umlaut over (x)}.sub.i.alpha..sup.2P,
X.sub.i, X.sub.j).di-elect cons..sub.q* (here C does not know rb)
[0245] Compute s=H.sub.7( . . . , X.sub.j).di-elect cons..sub.q*
[0246] By definition .gamma.=rX.sub.j=r{umlaut over
(x)}.sub.j.alpha.bP [0247] Compute the re-encryption key
RK.sub.i.fwdarw.j=(R.sub.1, R.sub.2, R.sub.3, R.sub.4, R.sub.5,
R.sub.6) where, [0248] R.sub.1= . . . h.sub.o.di-elect cons..sub.q*
[0249] R.sub.2=rbP.di-elect cons. [0250]
R.sub.3=(.omega..parallel.X.sub.i).sym.H.sub.8 ( . . . ,
X.sub.j).di-elect cons.{0, 1}.sup.l.sup.w.sup.+l.sup.3 [0251]
R.sub.4=H.sub.6 (.omega., . . . , X.sub.i, X.sub.j).di-elect
cons..sub.q* [0252] R.sub.5=h.sub.5.di-elect cons.{0,
1}.sup.l.sup.5, Store (t.sub.w, . . . , X.sub.i, h.sub.5) in
L.sub.H.sub.5 list [0253] R.sub.6=H.sub.0 (t.sub.w) [0254] Output
the re-encryption key RK.sub.i.fwdarw.j=(R.sub.1, R.sub.2, R.sub.3,
R.sub.4, R.sub.5, R.sub.6)
[0255] Self-Encrypt Oracle: On input of (m, t.sub.w, PK.sub.i), C
does the following: [0256] if PK.sub.i corrupt, then run
Self-Encrypt (m, t.sub.w, SK.sub.i, PK.sub.i) [0257] If PK.sub.i is
honest, then perform the following [0258] Choose random t.di-elect
cons..sub.q* [0259] Choose h.sub.t.di-elect cons..sub.q* and store
(t.sub.w, . . . , X.sub.i, h.sub.i) in L.sub.H.sub.l list. [0260]
Compute C.sub.1=t+h.sub.t. [0261] Compute Key=H.sub.2(t) [0262]
Compute C.sub.2={C.sub.i}.sub.(for i=1 to l) and C.sub.i=Sym.
Encrypt (M.sub.i, Key) for all i=1 to l, l is the number of blocks.
Assume than m=M.sub.1 M.sub.2 . . . M.sub.l where |M.sub.i|=k and k
is the block size of .DELTA.. [0263] Set C.sub.3=H.sub.3 (m, t)
[0264] Choose .alpha..di-elect cons.{0, 1}.sup.l.sup.5 and store
(t.sub.w, x.sub.i, X.sub.i, h.sub.5=.alpha.) in L.sub.H.sub.5 list.
[0265] C.sub.4=H.sub.4 (C.sub.1, C.sub.2, C.sub.3, .alpha., X)
[0266] Set C.sub.5=H.sub.9(t.sub.w) [0267] Store (C, t.sub.w,
PK.sub.i) in L.sub.Encrypt list. [0268] Output the ciphertext
C=(C.sub.1, H.sub.c (C.sub.2), C.sub.3, C.sub.4, C.sub.5)).
[0269] Re-Encrypt Oracle: On input C=(C.sub.1, C.sub.2, C.sub.3,
C.sub.4, C.sub.5, PK.sub.i, PK.sub.j), C does the following: [0270]
Generate the re-encryption key RK.sub.i.fwdarw.j=ReKey (PK.sub.i,
PK.sub.j) [0271] Run D=Re-Encrypt (C, RK.sub.i.fwdarw.j, PK.sub.i,
PK.sub.j) as per the algorithm. [0272] Store (C, D, PK.sub.i,
PK.sub.j, t.sub.w) in L.sub.Re-Encrypt list and output D
[0273] Self-Decrypt Oracle: On input C={C.sub.1, C.sub.2, C.sub.3,
C.sub.4, C.sub.5, t.sub.w, PK.sub.i}. C does the following: [0274]
If an entry for (C, t.sub.w, X.sub.i) is there in L.sub.Encrypt
list, return the corresponding m. [0275] if PK.sub.i corrupt, then
run Self-Decrypt (C, SK.sub.i) [0276] If PK.sub.i is honest, then
perform the following: [0277] Find (t.sub.w, x, X, h.sub.5) from
L.sub.H.sub.5 list such that (X.sub.i=xP) OR (X=X.sub.i AND x= . .
. ). Set .alpha.=h.sub.5. If there is no such entry then query
.alpha.=H.sub.5 (t.sub.w, . . . , X.sub.i). [0278] If
C.sub.4.noteq.H.sub.4 (C.sub.1, C.sub.2, C.sub.3, .alpha., t.sub.w,
X), then it returns .perp.. Find (t.sub.w, x, X. h.sub.1) from
L.sub.H.sub.1 list such that (X.sub.i=xP) OR (X=X.sub.i AND x=-).
Set .alpha.=h.sub.5. If there is no such entry query
.alpha.=H.sub.5 (t.sub.w, . . . , X.sub.i). [0279] Find (t.sub.w,
x, X, h.sub.1) from L.sub.H.sub.1 list such that (X.sub.i=xP) OR
(X=X.sub.i AND x=-), then set h.sub.t=h.sub.1. If there is no such
entry query then h.sub.t=H.sub.1 (t.sub.w, . . . , X.sub.i). [0280]
t=C.sub.1-h.sub.t [0281] Key=H.sub.2(t) [0282] Compute
M.sub.i=Sym.Decrypt (C.sub.i, Key) for all i=1 to l and construct
m=M.sub.1 M.sub.2 . . . M.sub.l. [0283] If C.sub.3H.sub.3 (m, t)
then, output m. Else, Output .perp.
[0284] Re-Decrypt Oracle: On input D=(D.sub.1, D.sub.2, D.sub.3,
D.sub.4, D.sub.5, t.sub.w, PK.sub.j), C does the following: [0285]
if PK.sub.j corrupt, then run Re-Decrypt (D, SK.sub.j) [0286] If
PK.sub.i and PK.sub.j are honest, then perform the following [0287]
1. Pick .gamma., h.sub.8 from (.gamma., X, h.sub.8) L.sub.H.sub.8
list for X=X.sub.j and [0288] 2. For each .gamma. retrieved from
L.sub.H.sub.8 list: compute
.omega..parallel.X.sub.i=D.sub.5.sym.h.sub.8 and r=H.sub.6
(.omega., {umlaut over (x)}.sub.j{umlaut over
(x)}.sub.i.alpha..sup.2P, X.sub.i, X.sub.j). If .gamma.=rX.sub.j,
then proceed with the next step, else continue checking with other
.gamma. retrieved from L.sub.H.sub.8 list. If no such .gamma. is
found, then it returns .perp.. [0289] 3. Compute s=H.sub.7 (r,
X.sub.j).di-elect cons..sub.q* [0290] 4. .rho.=H.sub.8 (.omega.,
.gamma., X.sub.i, X.sub.j).di-elect cons..sub.q* [0291] 5. Compute
.beta.=H.sub.9 (D.sub.6, .rho.).di-elect cons..sub.q* [0292] 6.
Compute t=.beta..sup.. . . 1 (D.sub.1) . . . [0293] 7. Find
Key=H.sub.2(t) [0294] 8. Compute M.sub.i=Sym.Decrypt (C.sub.i, Key)
for all i=1 to l and construct m=M.sub.1 M.sub.2 . . . M.sub.l.
[0295] 9. If (C.sub.3H.sub.3 (m, t)) then, output m. Else, it
returns .perp..
[0296] Challenge Phase: Once the training is over, provides
m.sub.0, m.sub.1.di-elect cons. such that (m.sub.0, t.sub.w*) or
(m.sub.1, t.sub.w*) was not queried to Self-Encrypt oracle during
Phase-1 and provides to C. C generates the challenge ciphertext
C*=Self-Encrypt (m.sub..delta., t.sub.w*) and .delta..di-elect
cons..sub.R {0, 1}
[0297] Phase-2 and Guess algorithms, can be described as follows,
for example in one embodiment.
[0298] Phase-2: can interact with the oracles provided in Phase-1
with the following restrictions, [0299] cannot make the query
Self-Decrypt(C*) [0300] cannot make the query Self-Encrypt(m.sub.6,
t.sub.w*), .delta..di-elect cons.{0, 1} [0301] cannot make the
query Re-Encrypt(C*, PK.sub.T, PK.sub.j), PK.sub.j.di-elect
cons.L.sub.Corrupt [0302] cannot make the query Re-Decrypt(D,
PK.sub.j), if D=Re-Encrypt(C*, PK.sub.T, PK.sub.j) and
PK.sub.j.di-elect cons.L.sub.Honest [0303] cannot make the query
ReKey(t.sub.w*, PK.sub.T, PK.sub.j) and PK.sub.j.di-elect
cons.L.sub.Corrupt
[0304] Guess: After getting sufficient training, output the guess
.delta.'. wins the game if .delta.=.delta.'. C now picks randomly
.gamma. from L.sub.H.sub.5 list and provides as solution to the CDH
problem. .quadrature.
Security of the Transformed Ciphertext
[0305] Theorem 3. If .alpha. (t, ) adversary with an advantage
breaks the IND-SE-PRE-CCA.sub.T security of the SE-PRE scheme, then
C can solve the Computational Diffie Hellman (CDH) problem with
advantage ' where,
' .gtoreq. 1 q t .times. ##EQU00005##
Here, q.sub.i is the number of queries to H.sub.6 oracle. [0306]
Proof: In this section we formally prove the security of the
transformed ciphertext of SE-PRE scheme in the random oracle model.
The security of the scheme is reduced to the CDH problem. The
challenger is given the instance of CDH (i.e. given (q, P,
.alpha.P, bP) such that q is a large prime, P, .alpha.P,
bP.di-elect cons., find Y such that Y=.alpha.bP.) Now, if there
exist an adversary who can break the IND-SE-PRE-CCA.sub.T security
of SE-PRE then C can make use of to solve the CDH problem, which is
assumed to be hard. Hence such an does not exist.
[0307] All the oracles are similar to that of IND-SE-PRE-CCA.sub.O.
The challenge ciphertext issued will be a transformed ciphertext.
has much more access than IND-SE-PRE-CCA.sub.O: [0308] is allowed
to access the rekey from PK.sub.T and PK.sub.j. [0309] is allowed
to access Self-Decrypt for PK.sub.T
[0310] Challenge: After getting sufficient training provides two
messages m.sub.0, m.sub.1 and gives to C. C generates the
ciphertext as, [0311] Generate C*=Self-Encrypt(m.sub.8, t.sub.w*,
PK.sub.i); PK.sub.i.di-elect cons.L.sub.Honest [0312] Generate
D*=RE-Encrypt(C*, t.sub.w*, PK.sub.i, PK.sub.T); [0313] Provides D*
to .
[0314] In Phase-2. is now allowed to access all the oracles except
Re-Decrypt(D*, PK.sub.T). The rest of the proof is similar to
IND-SE-PRE-CCA.sub.O. .quadrature.
[0315] Experimental Analysis provides the implementation results
and time taken by various algorithms in SE and SE-PRE scheme. We
compare the efficiency of our CCA secure SE scheme with the
traditional CPA secure El-Gamal scheme (Weaker security than CCA)
and report the same in FIG. 2 Table.1. Also, we have compared our
SE-PRE scheme with the only non-pairing unidirectional CCA secure
PRE scheme by others available. This is reported in FIG. 2 Table.2.
It is a known fact that pairing is very expensive than other group
operations and hence we are not taking any pairing based schemes
into consideration. The implementations are done on 2.4 GHz Intel
Core i7 quad-core processor and the results have been reported
below. The programming language used is Go language, and the
programming tool is Goland 2018.2. The cryptographic protocols are
implemented using the edwards25519-curve, which is the current
standard deployed in cryptocurrencies for fast performances. From
the performance comparison in FIG. 2 Table 1, we note that our CCA
secure self-encryption SE scheme is more efficient than the
existing CPA-secure El-Gamal encryption scheme. Also, from FIG. 2
Table 2, it is evident that our self-proxy re-encryption SE-PRE
scheme without bilinear pairing is more efficient than the existing
pairing-free PRE scheme by others.
[0316] From the above results it is evident that our SE encryption
scheme is practical and suitable for cloud based scenarios where
the user themselves store their files. Also, the SE-PRE scheme
provides a very efficient approach to share encrypted files mainly
in block-chain.
[0317] We have given a self encryption scheme SE based on discrete
logarithm (DLP) assumption and then extended it to a Proxy
Re-Encryption(SE-PRE) scheme suitable for blockchain and
distributed storage. First, we formally prove the CCA security of
the SE and then the security of SE-PRE scheme in the random oracle
model. We have also implemented our SE-PRE scheme using GO
language. From the results of our implementation, it is evident
that our SE-PRE scheme is much efficient than the techniques
available in literature and industry till date. This makes it more
suitable for distributed applications. A person of ordinary skill
in the art would understand that one can design a multi-recipient
or broadcast PRE based on the self encryption approach that will
provide high efficiency gain in decentralized platforms.
[0318] FIG. 3 is an exploded view of an intermediary system 120 in
FIG. 1 according to one embodiment disclosing self-encryption in
proxy re-encrypt scheme. Different modules within the intermediary
system that operate according to the disclosures herein are
described. For example, module 370 receives ciphertext from one or
more clients. Module 310 process the received ciphertext and
extracts the sender, i.e. the first user. Module 310 further
extracts the second user to whom the request is supposed to be
re-sent. Module 320 validates that the ciphertext originated from
first user. If the ciphertext is not validated, it is discarded
immediately and no further action is taken on that ciphertext. If
the ciphertext is not validated, error correcting mechanisms may be
employed to check whether the ciphertext is corrupt because of
network connection failure or an attack by an intruder. Module 330
re-encrypts the ciphertext based on the re-encryption key created
by first user using second user's public key. Module 340, outputs
the re-encrypted ciphertext only if original ciphertext was
validated. Module 350 provides security against chosen cipher
attack and denial of service attack. Module 360 as a proxy sends
the reencrypted ciphertext to the second user.
II. Secure Content Access Audit with blockchain
[0319] We provide a fast finality blockchain with cost effective
solution that allows for independent verifiable audit capability
along with providing end to end security for content from authoring
to distribution.
[0320] FIG. 4 discloses a data workflow 400 for an encrypted file
that requires independent audit response. For example, encrypted
file 430 is put on the blockchain platform by an authenticated
owner 410. In one embodiment, the owner 410 is authenticated using
proof of past public/private key transactions on the blockchain
platform. In one embodiment, the owner 410 is authenticated using
split-keys on two or more owner devices. In one embodiment, the
owner 410 is authenticated using a combination of single signature
on and split-key authentication techniques. Different users and
clients 420 can access the encrypted file 430 on an ongoing basis
according to security policy parameters set by owner. The security
policy parameters for the encrypted file 430 are enforced by an
intermediary 450. Another intermediary 440 can provide audit
services for the encrypted file.
[0321] FIG. 5 is integration at the server level. The idea here is
that the end users will not have any changes to their workflows.
Everything is taken care of at the server level. Whenever a user
submits data or reads data, it is automatically recorded on the
blockchain by the server. This level of integration provides
tamperproof auditability with accurate timestamp information. It is
assumed that the server is trusted at any given moment to submit
the right data to the blockchain but will not be able to alter it
later on.
[0322] FIG. 6 shows integration at the server and client level.
There may be cases where even the server can't be trusted. Or the
enterprise wants the audit data to be provided by the client
instead of the server. In this case, it is expected that each user
has credentials with the blockchain and use those credentials to
submit their read/write transactions and then present that as a
proof to the server to access the content. The server can continue
to enforce access control and even record any access that is not
permitted presenting the transaction presented by the user to read
the content.
[0323] In one embodiment, there is integration at the storage level
for enterprises. There are cases where the enterprise prefers to
have a zero-knowledge storage system. In this model, the storage of
the data is done in a decentralized manner by storage providers and
each has access to only a partial content that is also further
secured via encryption. The end user controls the keys to the
content and distribute it to users of their choice via proxy
re-encryption keys.
[0324] FIG. 7 is a schematic diagram of computing device 700 that
can be used to implement the methods and systems disclosed herein,
according to one or more embodiments. FIG. 7 is a schematic of a
computing device 700 that can be used to perform and/or implement
any of the embodiments disclosed herein. In one or more
embodiments, client system 110, an intermediary system 120, service
provider system 130 of FIG. 1 may be the computing device 700.
[0325] The computing device 700 may represent various forms of
digital computers, such as laptops, desktops, workstations,
personal digital assistants, servers, blade servers, mainframes,
and/or other appropriate computers. The computing device 700 may
represent various forms of mobile devices, such as smartphones,
camera phones, personal digital assistants, cellular telephones,
and other similar mobile devices. The components shown here, their
connections, couples, and relationships, and their functions, are
meant to be exemplary only, and are not meant to limit the
embodiments described and/or claimed.
[0326] FIG. 7 shows an example of a computing device 700 on which
techniques described here can be implemented. The computing device
700 can be a conventional computer system that can be used as a
client computer system, such as a wireless client or a workstation,
or a server computer system. The computing device 700 includes a
computer 705, I/O devices 710, and a display device 715. The
computer 705 includes a processor 720, a communications interface
725, memory 730, display controller 735, non-volatile storage 740,
and I/O controller 745. The computer 705 may be coupled to or
include the I/O devices 710 and display device 715.
[0327] The computer 705 interfaces to external systems through the
communications interface 725, which may include a modem or network
interface. It will be appreciated that the communications interface
725 can be considered to be part of the computing device 700 or a
part of the computer 705. The communications interface 725 can be
an analog modem, integrated services for digital networks ("ISDN")
modem, cable modem, token ring interface, satellite transmission
interface (e.g.
[0328] "direct personal computer" also known as "direct PC"), or
other interfaces for coupling a computer system to other computer
systems.
[0329] The processor 720 may be, for example, a conventional
microprocessor such as an Intel Pentium microprocessor or Motorola
power PC microprocessor. The memory 730 is coupled to the processor
720 by a bus 750. The memory 730 can be Dynamic Random Access
Memory (DRAM) and can also include Static RAM (SRAM). The bus 750
couples the processor 720 to the memory 730, also to the
non-volatile storage 740, to the display controller 735, and to the
I/O controller 745.
[0330] The I/O devices 710 can include a keyboard, disk drives,
printers, a scanner, and other input and output devices, including
a mouse or other pointing device. The display controller 735 may
control in the conventional manner a display on the display device
715, which can be, for example, a cathode ray tube (CRT) or liquid
crystal display (LCD). The display controller 735 and the I/O
controller 745 can be implemented with conventional well-known
technology.
[0331] The non-volatile storage 740 is often a magnetic hard disk,
an optical disk, or another form of storage for large amounts of
data. Some of this data is often written, by a direct memory access
process, into memory 730 during execution of software in the
computer 705. One of skill in the art will immediately recognize
that the terms "machine-readable medium" or "computer-readable
medium" includes any type of storage device that is accessible by
the processor 720 and also encompasses a carrier wave that encodes
a data signal.
[0332] The computing device 700 is one example of many possible
computer systems that have different architectures. For example,
personal computers based on an Intel microprocessor often have
multiple buses, one of which can be an I/O bus for the peripherals
and one that directly connects the processor 720 and the memory 730
(often referred to as a memory bus). The buses are connected
together through bridge components that perform any necessary
translation due to differing bus protocols.
[0333] Network computers are another type of computer system that
can be used in conjunction with the teachings described here.
Network computers do not usually include a hard disk or other mass
storage, and the executable programs are loaded from a network
connection into the memory 730 for execution by the processor 720.
A Web TV system, which is known in the art, is also considered to
be a computer system, but it may lack some of the components shown
in FIG. 7, such as certain input or output devices. A typical
computer system will usually include at least a processor, memory,
and a bus coupling the memory to the processor.
[0334] Though FIG. 7 shows an example of the computing device 700,
it is noted that the term "computer system," as used here, is
intended to be construed broadly. In general, a computer system
will include a processor, memory, non-volatile storage, and an
interface. A typical computer system will usually include at least
a processor, memory, and a device (e.g., a bus) coupling the memory
to the processor. The processor can be, for example, a
general-purpose central processing unit (CPU), such as a
microprocessor, or a special-purpose processor, such as a
microcontroller. An example of a computer system is shown in FIG.
7.
[0335] The memory can include, by way of example but not
limitation, random access memory (RAM), such as dynamic RAM (DRAM)
and static RAM (SRAM). The memory can be local, remote, or
distributed. As used here, the term "computer-readable storage
medium" is intended to include only physical media, such as memory.
As used here, a computer-readable medium is intended to include all
mediums that are statutory (e.g., in the United States, under 35
U.S.C. 101), and to specifically exclude all mediums that are
non-statutory in nature to the extent that the exclusion is
necessary for a claim that includes the computer-readable medium to
be valid. Known statutory computer-readable mediums include
hardware (e.g., registers, random access memory (RAM), non-volatile
(NV) storage, to name a few), but may or may not be limited to
hardware.
[0336] The bus can also couple the processor to the non-volatile
storage. The non-volatile storage is often a magnetic floppy or
hard disk, a magnetic-optical disk, an optical disk, a read-only
memory (ROM), such as a CD-ROM, EPROM, or EEPROM, a magnetic or
optical card, or another form of storage for large amounts of data.
Some of this data is often written, by a direct memory access
process, into memory during execution of software on the computer
system. The non-volatile storage can be local, remote, or
distributed. The non-volatile storage is optional because systems
can be created with all applicable data available in memory.
[0337] Software is typically stored in the non-volatile storage.
Indeed, for large programs, it may not even be possible to store
the entire program in the memory. Nevertheless, it should be
understood that for software to run, if necessary, it is moved to a
computer-readable location appropriate for processing, and for
illustrative purposes, that location is referred to as the memory
here. Even when software is moved to the memory for execution, the
processor will typically make use of hardware registers to store
values associated with the software, and local cache that, ideally,
serves to speed up execution. As used here, a software program is
assumed to be stored at an applicable known or convenient location
(from non-volatile storage to hardware registers) when the software
program is referred to as "implemented in a computer-readable
storage medium." A processor is considered to be "configured to
execute a program" when at least one value associated with the
program is stored in a register readable by the processor.
[0338] In one example of operation, a computer system can be
controlled by operating system software, which is a software
program that includes a file management system, such as a disk
operating system. One example of operating system software with
associated file management system software is the family of
operating systems known as Windows.RTM. from Microsoft Corporation
of Redmond, Wash., and their associated file management systems.
Another example of operating system software with its associated
file management system software is the Linux operating system and
its associated file management system. The file management system
is typically stored in the non-volatile storage and causes the
processor to execute the various acts required by the operating
system to input and output data and to store data in the memory,
including storing files on the non-volatile storage.
[0339] The bus can also couple the processor to the interface. The
interface can include one or more input and/or output (I/O)
devices. The I/O devices can include, by way of example but not
limitation, a keyboard, a mouse or other pointing device, disk
drives, printers, a scanner, and other I/O devices, including a
display device. The display device can include, by way of example
but not limitation, a cathode ray tube (CRT), liquid crystal
display (LCD), or some other applicable known or convenient display
device. The interface can include one or more of a modem or network
interface. It will be appreciated that a modem or network interface
can be considered to be part of the computer system. The interface
can include an analog modem, isdn modem, cable modem, token ring
interface, satellite transmission interface (e.g. "direct PC"), or
other interfaces for coupling a computer system to other computer
systems. Interfaces enable computer systems and other devices to be
coupled together in a network.
[0340] Several components described here, including clients,
servers, and engines, can be compatible with or implemented using a
cloud-based computing system. As used here, a cloud-based computing
system is a system that provides computing resources, software,
and/or information to client systems by maintaining centralized
services and resources that the client systems can access over a
communications interface, such as a network. The cloud-based
computing system can involve a subscription for services or use a
utility pricing model. Users can access the protocols of the
cloud-based computing system through a web browser or other
container application located on their client system.
[0341] The invention disclosure describes techniques that those of
skill in the art can implement in numerous ways. For instance,
those of skill in the art can implement the techniques described
here using a process, an apparatus, a system, a composition of
matter, a computer program product embodied on a computer-readable
storage medium, and/or a processor, such as a processor configured
to execute instructions stored on and/or provided by a memory
coupled to the processor. Unless stated otherwise, a component such
as a processor or a memory described as being configured to perform
a task may be implemented as a general component that is configured
to perform the task at a given time or a specific component that is
manufactured to perform the task. As used here, the term
`processor` refers to one or more devices, circuits, and/or
processing cores configured to process data, such as computer
program instructions.
[0342] A detailed description of one or more implementations of the
invention is provided here along with accompanying figures that
illustrate the principles of the invention. The invention is
described in connection with such implementations, but the
invention is not limited to any implementation. The scope of the
invention is limited only by the claims and the invention
encompasses numerous alternatives, modifications and equivalents.
Numerous specific details are set forth in the following
description in order to provide a thorough understanding of the
invention. These details are provided for the purpose of example
and the invention may be practiced according to the claims without
some or all of these specific details. For the purpose of clarity,
technical material that is known in the technical fields related to
the invention has not been described in detail so that the
invention is not unnecessarily obscured.
[0343] Some portions of the detailed description are presented in
terms of algorithms and symbolic representations of operations on
data bits within a computer memory. These algorithmic descriptions
and representations are the means used by those skilled in the data
processing arts to most effectively convey the substance of their
work to others skilled in the art. An algorithm is here, and
generally, conceived to be a self-consistent sequence of operations
leading to a desired result. The operations are those requiring
physical manipulations of physical quantities. Usually, though not
necessarily, these quantities take the form of electrical or
magnetic signals capable of being stored, transferred, combined,
compared, and otherwise manipulated. It has proven convenient at
times, principally for reasons of common usage, to refer to these
signals as bits, values, elements, symbols, characters, terms,
numbers, or the like.
[0344] It should be borne in mind, however, that all of these and
similar terms are to be associated with the appropriate physical
quantities and are merely convenient labels applied to these
quantities. Unless specifically stated otherwise as apparent from
the following discussion, it is appreciated that throughout the
description, discussions utilizing terms such as "processing" or
"computing" or "calculating" or "determining" or "displaying" or
the like, refer to the action and processes of a computer system,
or similar electronic computing device, that manipulates and
transforms data represented as physical (electronic) quantities
within the computer system's registers and memories into other data
similarly represented as physical quantities within the computer
system memories or registers or other such information storage,
transmission or display devices.
[0345] Techniques described here relate to apparatus for performing
the operations. The apparatus can be specially constructed for the
required purposes, or it can comprise a general-purpose computer
selectively activated or reconfigured by a computer program stored
in the computer. Such a computer program may be stored in a
computer-readable storage medium, such as, but is not limited to,
read-only memories (ROMs), random access memories (RAMS), EPROMs,
EEPROMs, magnetic or optical cards, any type of disk including
floppy disks, optical disks, CD-ROMs, and magnetic-optical disks,
or any type of media suitable for storing electronic instructions,
and each coupled to a computer system bus. Although the foregoing
implementations have been described in some detail for purposes of
clarity of understanding, implementations are not necessarily
limited to the details provided.
III. Multiple Signatures on a Smart Wallet
[0346] In one embodiment, a smart wallet is made of Modern
Portfolio Theory (MPT) wallet. Users can add T-of-N multi-sig
capabilities to standard MPT wallets. Votes to send tokens must
arrive one-per-transaction and are stored in public blockchain
state. A group signature on a description of transfer is recovered
from the votes. Validation of the signature happens outside of the
smart contract. State may be pruned safely, allowing amnesiac
property of miners is preserved without loss of security.
[0347] In one embodiment, a single, shared smart contract collects
votes for proposals to send tokens between wallets. In one
embodiment, the wallet associated with the smart contract is not
used and multiple-signatures ("multi-sig") are sent directly on
standard modern portfolio theory ("MPT") based wallets. This
removes the support for non-token-transfer operations guarded by a
multi-sig, meaning in one embodiment, this design will not support
data transactions or arbitrary smart contract calls. The policy of
multi-sig is enforced automatically. In one embodiment, threshold
cryptography will be utilized to create signatures for the
exchange/corporate MPT wallet. In one embodiment, Shamir's secret
sharing is used as a simple way to create keys capable of this
feature. New transactions will not be dynamically created inside
the smart contract.
[0348] The benefits of implementing multiple signatures on a smart
wallet include creation of multi-signature wallets, voting for
transfers and pruning of old proposed transfers and votes. Any
implementation has to consider the following before finalizing
transactions on the smart wallet: querying whether multi-signature
capabilities already exist; updating the list of signers and/or
required number of votes; deletion of multi-signature capabilities
for a wallet.
[0349] Allow creation of a multiple signature wallet context for a
wallet. The transaction containing this request must be send from
the target wallet's client. It must include a list of voter public
keys and the minimum number of votes that must be collected before
funds may be sent from the wallet. If a wallet with this multi-sig
wallet context already exists, it is an error. Don't disallow
normal TxnTypeSend from a wallet for which a multi-sig wallet
context exists. Allow creation of multi-sig transfer votes for a
wallet. The votes must contain a proposal ID value to differentiate
between multiple transfers of the same value to the same client.
Different multi-sig wallet contexts may have proposals with the
same ID. When a vote is sent with an ID not currently in the
database, a proposal object is created in state. A vote must
contain an inner signature produced by the vote's sender. This
signature is on a message similar to the following: [0350]
"${FromWalletID}:${ToWalletID}:${Value}.
[0351] Add chaincore/chain/state_context.go#AddSignedTransfer( )
call that is similar to AddTransfer( ) but which also takes a
signature and may send from any wallet. This AddSignedTransfer call
reconstructs the message above and validates the passed signature
against it and from the wallet's public key. If the signature is
invalid, the call fails and the transfer is rejected.
[0352] When the required number of votes are collected on a
multi-sig send proposal, it is executed. If the wallet does not
have enough balance to complete the transaction, the vote
transaction succeeds (so as to eligible to be included in a block)
but does not count the vote toward the proposal and a transaction
output message that there aren't enough funds. Because the vote is
not counted, it allows the last voter to try again later. If the
transfer succeeds, the proposal object that was allocated for this
transfer is not deleted yet. This allows us to tell additional
votes that come in soon after that their proposal was already
executed.
[0353] Multi-sig proposals are assigned an expiration date by the
smart contract. When the expiration date is past, a proposal is
eligible for deletion.
[0354] When a vote comes in, the blockchain checks the oldest
proposal it knows of (across all multi-sig wallets, not just the
one being voted on) to see if it is expired. If so, it is deleted
("pruned") and the ID value that the proposal held is free to be
re-used by the originating multi-sig wallet. Only one proposal may
be deleted per incoming vote to protect against any single vote
transaction performing a large amount of IO. This will help to
future-proof this multi-sig wallet scheme from any IO quota policy
the blockchain might decide to one day start implementing.
[0355] If a vote comes in for a proposal that is past expiry but
which has not been pruned yet, the proposal is immediately deleted
("pruned") and a new proposal with the same ID is instantiated.
This presents a consistent behavior between an expired-deleted and
an expired-not-yet-deleted proposal.
[0356] In one embodiment, multiple signature smart wallet is
implemented as follows. First a user needs to do threshold
signature setup. As part of this setup, the user creates a desired
number of t-of-n private/public keys. Then the user recovers the
group private/public key. This group key is used to register a
group wallet on the blockchain and the token balance is stored
against this group client. Whenever the tokens in this group wallet
needs to be withdrawn, individual clients submit their share of the
transaction as a regular blockchain transaction. These individual
transactions contains a shared signature for a given transaction
payload which authorizes transfer of certain amount of tokens to a
specific client for a given context. When enough such signatures
(t) are recovered, then the group signature is recovered. This
group signature is presented to withdraw the funds. The blockchain
fund transfer API doesn't need to be aware of all this additional
setup. As far as it is concerned, it is transferring the funds
based on a signature of a wallet. This provides a secure multi-sig
capability.
[0357] In one embodiment, the use of group key and receipt of
signatures is implemented without smart contract voting. The scheme
seamlessly achieves all the functions of a single signature wallet.
It can be replace a single signature wallet without any additional
changes required to API or blockchain platform environment.
[0358] FIG. 8 shows 800 multiple-signature wallet flow for messages
between different entities. At 810 is Administrator of the
blockchain, 820 is the Exchange application for transactions,
830-1,2,3, . . . n are different multiple signers, 840 is the smart
contract, 850 is modern portfolio theory wallet, 860 is the
depositor and 870 is the withdrawer. The figure shows register,
deposit and withdraw events and corresponding messages according to
one embodiment.
[0359] FIG. 9 shows 900 multiple-signature wallet flow for messages
between different entities in one embodiment. At 910 is the
Administrator, 920 is the Exchange application, Signers are at
930-1,2,3, . . . n, 940 is the shared multiple-signature wallet
associated with a smart contract, 950 is the modern portfolio
theory wallet, 960 is the depositor, and 970 is the withdrawer. The
figure shows register, deposit and withdraw events and
corresponding messages according to one embodiment.
IV. Split Key Authentication and Password-Less Login
[0360] Blockchain platform with a novel split-key1 mechanism is
used to provide more secure authentication and password-less login.
Interestingly the same scheme can also be used in an enterprise SSO
setting by replacing the traditional password based login with a
more secure authentication using only digital keys and just using
the laptop/desktop and mobile app and no special hardware.
[0361] The value proposition for this approach is a higher security
and an easier password-less login flow, without the need for
hardware devices, fingerprint, or face recognition schemes as this
approach has a built-in higher level of security. The latter
methods can still be added as an add-on to further bolster the
security of the login process.
[0362] Enterprises already use SSO to make it easy for their
employees to login to their various internal application that each
require login. Existing solutions rely on password based
authentication. And some require changing the password every few
weeks or months. Some even prevent reusing the previous 10
passwords, making it extremely painful to employees. While this
improves the security, it imposes unnecessary burden on the
employees.
[0363] In one embodiment, a novel split key based signature scheme
is used that requires two separate signatures from two split keys
(of the primary key) to create the combined signature. These
partial signatures are constructed on two separate devices to
enhance the security. Compromise of one key doesn't result in the
compromise of the primary key. This technique can be used to
provide authentication service to existing SSO servers.
[0364] Below is the outline of the first-time registration and
subsequent login processes. Registration: 1) User accesses the SSO
login page in the browser. 2) User is presented with the familiar
login form. 3) User does the login by entering username and
password. 4) At this time, the SSO server will work with blockchain
IDP server and identify the user needs to register into the split
key IDP service. 5) Blockchain IDP provides a session ID and a
challenge tracking that the SSO server sends to the User. 6) User's
browser redirects and opens a desktop app. 7) The desktop app has
the ability to connect to a mobile device via a short range
wireless connection, for example, a bluetooth protocol or near
field communications protocols. 8) The desktop will sign the
challenge partial key and send the signature to the mobile. 9) The
mobile will sign the challenge with its own partial key, combine
the signatures and respond back to the blockchain IDP server along
with the primary public key. 10) The blockchain IDP server confirms
that the signature is valid with respect to the public key and
registers the phone and the public key against the user. 11)
Blockchain IDP server responds to SSO of the successful
registration. 12) SSO server redirects the user to the
application.
[0365] Password-less Login: 1) User accesses the SSO login page in
the browser. 2) User is presented with the familiar login form. In
addition, there will be a link to use the split key based
authentication (note that this extra step of clicking the link can
be bypassed if there is a cookie information from a prior session
that user is already setup for split key authentication). 3) SSO
server works with blockchain IDP server and provides a challenge.
This will happen either directly as a response to step 1 or after
user explicitly clicks the link to use split key authentication in
step 2 (that depends on the cookie information). 4) Browser
redirects and opens the desktop app. 5) The flow from here is same
as the Registration process from step 7.
[0366] Note that the desktop app is only required at this time
because of the local communication with the mobile phone. As Web
Bluetooth API becomes widely adopted, the desktop app can be
completely eliminated and the communication will happen directly
between the browser and the mobile phone.
[0367] Also, in the above description, the SSO server and
blockchain IDP service are mentioned as two separate servers.
However, it is also possible to make blockchain IDP service
available as a pluggable module into existing SSO solutions.
[0368] FIG. 10 shows the message flow 1000 for split-key
authentication according to one embodiment. At 1010 is the user,
1020 is the desktop or first device of the user, 1030 is the second
device or mobile of the user, 1040 is the Single-sign on ("SSO")
server, 1050 is the Blockchain IDP Server. The figure shows
Register and Login events and corresponding message flow according
to one embodiment.
[0369] FIG. 11 is depicts a flowchart 1100 illustrating an example
of a method for a blockchain platform to achieve split-key
authentication and passwordless login, according to one embodiment.
The flowchart 1100 is discussed in conjunction with the blockchain
platform environment shown in the diagram 100 in FIG. 1. At block
1105, for a given client login, create a public and private key at
a client device. At block 1110, split the private key of the client
into two or more parts. At block 1115, assign the split private key
part to two or more client devices. At 1120, signing to
authenticate a challenge using a partial key part at one of the
client devices. At 1125, send the challenge to the remaining client
devices who sequentially sign using short range wireless network
connection, for example, Bluetooth protocol or near field
communication. At 1130, respond back to the challenge to login
without a password. At 1135, receive authentication complete based
on the response to the challenge. At 1140, getting access to the
application or resources based on the authentication.
[0370] In broad embodiment, the invention is systems and methods of
a blockchain platform for intermediaries to provide different
services including proxy re-encryption, independent audit services,
multi-sig smart wallet and split-key based passwordless login.
[0371] A number of embodiments have been described. Nevertheless,
it will be understood that various modifications may be made
without departing from the spirit and scope of the claimed
invention. In addition, the logic flows depicted in the figures do
not require the particular order shown, or sequential order, to
achieve desirable results. In addition, other steps may be
provided, or steps may be eliminated, from the described flows, and
other components may be added to, or removed from, the described
systems. Accordingly, other embodiments are within the scope of the
following claims.
[0372] It may be appreciated that the various systems, methods, and
apparatus disclosed herein may be embodied in a machine-readable
medium and/or a machine accessible medium compatible with a data
processing system (e.g., a computer system), and/or may be
performed in any order.
[0373] The structures and modules in the figures may be shown as
distinct and communicating with only a few specific structures and
not others. The structures may be merged with each other, may
perform overlapping functions, and may communicate with other
structures not shown to be connected in the figures.
[0374] The above-described functions and components may be
comprised of instructions that are stored on a storage medium such
as a computer readable medium. The instructions may be retrieved
and executed by a processor. Some examples of instructions are
software, program code, and firmware. Some examples of storage
medium are memory devices, tapes, disks, integrated circuits, and
servers. The instructions are operational when executed by the
processor to direct the processor to operate in accord with some
embodiments. Those skilled in the art are familiar with
instructions, processor(s), and storage medium.
[0375] While the foregoing written description of the invention
enables one of ordinary skill to make and use what is considered
presently to be the best mode thereof, those of ordinary skill will
understand and appreciate the existence of variations,
combinations, and equivalents of the specific embodiment, method,
and examples herein. The invention should therefore not be limited
by the above described embodiment, method, and examples, but by all
embodiments and methods within the scope and spirit of the
invention.
[0376] A detailed description of one or more implementations of the
invention is provided here along with accompanying figures that
illustrate the principles of the invention. The invention is
described in connection with such implementations, but the
invention is not limited to any implementation. The scope of the
invention is limited only by the claims and the invention
encompasses numerous alternatives, modifications and equivalents.
Numerous specific details are set forth in the following
description in order to provide a thorough understanding of the
invention. These details are provided for the purpose of example
and the invention may be practiced according to the claims without
some or all of these specific details. For the purpose of clarity,
technical material that is known in the technical fields related to
the invention has not been described in detail so that the
invention is not unnecessarily obscured.
[0377] The structures and modules in the figures may be shown as
distinct and communicating with only a few specific structures and
not others. The structures may be merged with each other, may
perform overlapping functions, and may communicate with other
structures not shown to be connected in the figures.
* * * * *