done questionmark
This commit is contained in:
parent
2cd4721db1
commit
28b1953d16
39
report.tex
39
report.tex
|
|
@ -41,7 +41,7 @@
|
|||
\newcommand{\AHBE}{\texttt{AHBE}\xspace}
|
||||
\newcommand{\overbar}[1]{\mkern 1.5mu\overline{\mkern-1.5mu#1\mkern-1.5mu}\mkern 1.5mu}
|
||||
\newcommand{\KHBE}{\texttt{KHBE}\xspace}
|
||||
\newcommand{\mlarge}[1]{\mathlarger{\mathlarger{\mathlarger{#1}}}}
|
||||
\newcommand{\mlarge}[1]{\mathlarger{\mathlarger{#1}}}
|
||||
|
||||
% Use dash instead of bullets for itemize
|
||||
\renewcommand\labelitemi{--}
|
||||
|
|
@ -69,7 +69,7 @@ By definition, \emph{Encryption} is the process of converting information into a
|
|||
|
||||
Now, imagine a scenario where a user has an entire network of people in which he only wishes to send to a subset of these at a time. In the world of \texttt{PKE}, this user will have to fetch each users public key and encrypt the same symmetric key for each user, resulting in a ciphertext for the same key for each user. This is highly inefficient, and becomes even worse if the \emph{authorised set} of receivers change, at which point a new symmetric key must be created and sent to each user. To this end, \emph{Broadcast Encryption}, \texttt{BE}, can be adopted as a solution. In such a scheme, a user will pick his set of recievers $S$, fetch their public keys, but only encrypt the key once and broadcast this. Thus, the resulting ciphertext of the key does not depend in any way on the number of users, and there is only a single message which can easily be broadcasted to all users of the system, but only those users within the set $S$ can decrypt it.
|
||||
|
||||
In this paper we first cover the concept of \emph{Identity Based Encryption}, \texttt{IBE}, as an introduction to some of the mathmatical concepts used within the paper, such as that of \emph{bilinear maps} and the mathmatical assumption that is the \emph{Bilinear Diffie Hellman}-problem. These two concepts can be extended and applied to many branches of encryption, such as \texttt{BE} or \emph{Threshold Public Key Encryption}, \texttt{TPKE}, both of which will also be introduced in this paper. Thus, we wish to introduce three different types of encryption schemes, \texttt{IBE, BE} and \texttt{TE}, give a notion of what security is defined to be for these as well as an actual construction and extension of these.
|
||||
In this paper we first cover the concept of \emph{Identity Based Encryption}, \texttt{IBE}, as an introduction to some of the mathmatical concepts used within the paper, such as that of \emph{bilinear maps} and the mathmatical assumption that is the \emph{Bilinear Diffie Hellman}-problem. These two concepts can be extended and applied to many branches of encryption, such as \texttt{BE} or \emph{Dynamic Threshold Public Key Encryption}, \texttt{DTPKE}, both of which will also be introduced in this paper. Thus, we wish to introduce three different types of encryption schemes, \texttt{IBE, BE} and \texttt{DTPKE}, give a notion of what security is defined to be for these as well as an actual construction and extension of these.
|
||||
|
||||
|
||||
\section{Syntax and Preliminaries}
|
||||
|
|
@ -169,17 +169,17 @@ This definition closely resembles the standard definition of \texttt{IND-CPA} bu
|
|||
\label{sec:IBEConst}
|
||||
The scheme we will focus on is that of Boneh and Franklin as described in \cite{WeilIBE}. The structure will be as defined in Section \ref{sec:IBEStruct}. We let $\lambda$ be the given security parameter given implicitly to the setup algorithm. We let $\mathcal{G}$ be a BDH parameter generator.
|
||||
\begin{description}
|
||||
\item[Setup] Given $\lambda$;
|
||||
\item[Setup$()$] Given $\lambda$;
|
||||
\begin{enumerate}
|
||||
\item Run $\mathcal{G}$ on the security parameter $\lambda$ in order to generate a prime $p$ which defines the order of two groups $\Gm$ and $\Gm_T$ as well as an \emph{admissible} bilinear map $e : \Gm \times \Gm \ra \Gm_T$. Pick a random generator $g \in_R \Gm$.
|
||||
\item Pick a random $s \in_R \mathbb{Z}^*_p$ and set the public key PK as such, $PK = g^s$.
|
||||
\item Choose two hash functions: $H_1 : \{0,1\}^* \ra G^*$ and $H_2 : G_T \ra \{0,1\}^n$ for some $n$. Note that in the security analysis of this scheme, $H_1$ and $H_2$ will be viewed as random oracles. \\
|
||||
The message space will be $\mathcal{M} = \{0,1\}^n$ and the ciphertext space is $\mathcal{C} = \Gm^{*} \times \{0,1\}^n$. Finally, the system parameters \texttt{params} are $(p, \Gm, \Gm_T, e, n, g, PK, H_1, H_2)$. The \emph{master key} (Or the systems private key), is then $s$. % TODO: Is this not the same s from the generation of the pk?
|
||||
The message space will be $\mathcal{M} = \{0,1\}^n$ and the ciphertext space is $\mathcal{C} = \Gm^{*} \times \{0,1\}^n$. Finally, the system parameters \textbf{params} are $(p, \Gm, \Gm_T, e, n, g, PK, H_1, H_2)$. The \emph{master key} (Or the systems private key), is then $s$. % TODO: Is this not the same s from the generation of the pk?
|
||||
\end{enumerate}
|
||||
\item[Extract] For a given string \ID $\in \{0,1\}^*$ the algorithm does two things; Compute $Q_{\mathtt{ID}} = H_1(ID) \in \Gm^*$ and it sets the private key $d_{\mathtt{ID}}$ to be $d_{\mathtt{ID}} = Q_{\mathtt{ID}}^s$, for the master key $s$.
|
||||
\item[Encrypt] To encrypt some $m \in \mathcal{M}$ under the public key \ID, the user does the following: Compute $Q_{\mathtt{ID}} = H_1(ID) \in \Gm^*$, choose a random $r \in_R \mathbb{Z}^*_p$ and set the final ciphertext to be:
|
||||
\item[Extract$(\mathtt{ID}, \mathbf{params}, s)$] For a given string \ID $\in \{0,1\}^*$ the algorithm does two things; Compute $Q_{\mathtt{ID}} = H_1(ID) \in \Gm^*$ and it sets the private key $d_{\mathtt{ID}}$ to be $d_{\mathtt{ID}} = Q_{\mathtt{ID}}^s$, for the master key $s$.
|
||||
\item[Encrypt$(\mathtt{ID}, \mathbf{params}, m)$] To encrypt some $m \in \mathcal{M}$ under the public key \ID, the user does the following: Compute $Q_{\mathtt{ID}} = H_1(ID) \in \Gm^*$, choose a random $r \in_R \mathbb{Z}^*_p$ and set the final ciphertext to be:
|
||||
$$C = (g^r, m \oplus H_2(g_{\mathtt{ID}}^r)\quad \text{ where }\quad g_{\mathtt{ID}} = e(Q_{\mathtt{ID}}, PK) \in \Gm^*_T$$
|
||||
\item[Decrypt] Parse $C = (u,v)$ as a ciphertext decrypted under the public key \texttt{ID}. Then, to decrypt $C$ using the private key $d_{\mathtt{ID}} \in \Gm^*$, compute:
|
||||
\item[Decrypt$(\mathtt{ID}, \mathbf{params}, C, d_{\mathtt{ID}})$] Parse $C = (u,v)$ as a ciphertext decrypted under the public key \texttt{ID}. Then, to decrypt $C$ using the private key $d_{\mathtt{ID}} \in \Gm^*$, compute:
|
||||
$$v \oplus H_2(e(d_{\mathtt{ID}}, u)) = m$$
|
||||
|
||||
Correctness of the above scheme is obvious from two facts;
|
||||
|
|
@ -202,17 +202,17 @@ Broadcast Encryption systems \cite{BEDef} in a nutshell, allows one sender to se
|
|||
|
||||
|
||||
\subsection{Modelling Broadcast Encryption}
|
||||
Broadcast Encryption systems can be defined as a \emph{Key Encapsulation Mechanism}, \texttt{KEM}, where what is actually encrypted is a symmetrical key, which can then be used for encryption and decryption at a later stage.
|
||||
Broadcast Encryption systems can be defined as a \emph{Key Encapsulation Mechanism}, \texttt{KEM}, where what is actually encrypted is a symmetric key, which can then be used for encryption and decryption at a later stage.
|
||||
|
||||
% TODO: BSetup takes n and ell, where ell defines the maximum size of the set. Ergo is the security parameter lambda implicit. Change this at later stages!
|
||||
\begin{description}
|
||||
\item[BSetup$(n, \ell)$] Here, $n$ defines the number of receivers and $\ell$ is the maximum size of the receiver set, $n \leq \ell$. Outputs a public/secret key pair, $(PK, SK)$ of the BE scheme.
|
||||
\item[KeyGen$(i, SK)$] $i$ defines a specific index for a user, $i \in [1,n]$, as well as the secret key $SK$. Outputs a decryption key $d_i$ specific for this user.
|
||||
\item[BSetup$(n, \ell)$] Here, $n$ defines the number of receivers and $\ell$ is the maximum size of the receiver set, $n \leq \ell$. Outputs a public/secret key pair, $(PK, SK)$ of the \texttt{BE} scheme.
|
||||
\item[BKeyGen$(i, SK)$] $i$ defines a specific index for a user, $i \in [1,n]$, as well as the secret key $SK$. Outputs a decryption key $d_i$ specific for this user.
|
||||
\item[BEnc$(S, PK)$] Takes as input some subset $S \subseteq [1,n]$ where $S$ will henceforth be known as the receiver or authorised set, as well as the public key of the BE scheme. Given that $|S| \leq \ell$, outputs a pair $(\hdr, K)$, where \hdr is called the \emph{header} and $K \in \mathcal{K}$ is the message encryption key. \hdr can be seen as the ciphertext for the key $K$, which in this case is a symmetrical key which can be used after having been extracted from the \hdr.
|
||||
\item[BDec$(S, i, d_i, \hdr, PK)$] Takes the receiver set $S$, an index $i \in [1,n]$, a corresponding decryption key, a \hdr and the public key PK. Given $|S| \leq \ell$ and $i \in S$, this extracts the key $K \in \mathcal{K}$ from \hdr.
|
||||
\item[Correctness] For all $S \subseteq [1,n]$ and all $i \in S$, if $(PK, SK) \xleftarrow{R} BSetup(n, \ell)$, $d_i \xleftarrow{R} KeyGen(i, SK)$ and $(\hdr, K) \xleftarrow{R} BEnc(S, PK)$, then $BDec(S, i, d_i, \hdr, PK) = K$, i.e. if a key $K \in \mathcal{K}$ is encrypted for a receiver set, then a user from within this receiver set can also extract the same $K$ from the \hdr.
|
||||
\item[Correctness] For all $S \subseteq [1,n]$ and all $i \in S$, if $(PK, SK) \xleftarrow{R} \mathbf{BSetup}(n, \ell)$, $d_i \xleftarrow{R} \mathbf{BKeyGen}(i, SK)$ and $(\hdr, K) \xleftarrow{R} \mathbf{BEnc}(S, PK)$, then $\mathbf{BDec}(S, i, d_i, \hdr, PK) = K$, i.e. if a key $K \in \mathcal{K}$ is encrypted for a receiver set, then a user from within this receiver set can also extract the same $K$ from the \hdr.
|
||||
|
||||
Ordinary \texttt{BE}-schemes require a trusted authority, like the \texttt{PKG} defined for \texttt{IBE}-schemes. This trusted authority will run the \textbf{BSetup} to get the $PK$ and $SK$ of the system and will then be used to generate the decryption keys for the users afterwards via the \textbf{KeyGen} algorithm, when a user requests so.
|
||||
Ordinary \texttt{BE}-schemes require a trusted authority, like the \texttt{PKG} defined for \texttt{IBE}-schemes. This trusted authority will run the \textbf{BSetup} to get the $PK$ and $SK$ of the system and will then be used to generate the decryption keys for the users afterwards via the \textbf{BKeyGen} algorithm, when a user requests so.
|
||||
\end{description}
|
||||
|
||||
\subsection{Security Defintions}
|
||||
|
|
@ -401,12 +401,12 @@ It should be noted that this scheme is very long and as such will be left out of
|
|||
|
||||
\section{Ad-Hoc Broadcast Encryption}
|
||||
\label{sec:AHBE}
|
||||
The scheme presented in \ref{sec:BE} requires a \emph{trusted dealer} to perform its \textbf{BSetup} and \textbf{KeyGen}. It goes for all of \emph{Broadcast Encryption} systems, that they require a trusted entity to generate and distribute secret keys to all users. This tends to make the system very rigid and not applicable to ad hoc networks or peer-to-peer networks. A \emph{potential} solution to this is presented by \cite{AHBE}. They present a solution to the fully dynamic case of broadcast encryption. This has significant ties to the \emph{Dynamic Threshold Encryption} scheme in which users could freely join and leave, however they did not quite get rid of the trusted dealer. This is accomplished here however.
|
||||
The scheme presented in \ref{sec:BE} requires a \emph{trusted dealer} to perform its \textbf{BSetup} and \textbf{BKeyGen}. It goes for all of \emph{Broadcast Encryption} systems, that they require a trusted entity to generate and distribute secret keys to all users. This tends to make the system very rigid and not applicable to ad hoc networks or peer-to-peer networks. A \emph{potential} solution to this is presented by \cite{AHBE}. They present a solution to the fully dynamic case of broadcast encryption. This has significant ties to the \emph{Dynamic Threshold Encryption} scheme in which users could freely join and leave, however they did not quite get rid of the trusted dealer. This is accomplished here however.
|
||||
|
||||
In an Ad-Hoc Broadcast Encryption (\texttt{AHBE}) scheme all users possess their own public key, which is independently generated by themselves with no need for a trusted authority or setup. Then, by only seeing the public keys of users, a sender can securely broadcast to \emph{any} subset of the users. Only users within the picked subset can decrypt the message. To accomplish this, the authors create a generic transformation from any \emph{key homomorphic} BE (\texttt{KHBE}) scheme to an \texttt{AHBE} scheme. It turns out that the scheme of Gentry and Waters presented in Section \ref{sec:BE} is just this and the transformation will be performed on this.
|
||||
|
||||
\subsection{Modelling Ad-Hoc Broadcast Encryption}
|
||||
As an \texttt{AHBE} system eliminate the trusted dealer, the \textbf{BSetup} and \textbf{KeyGen} step morph together, as there is no global \textbf{BSetup} step required, but merely something each user should locally run. As all other schemes defined in this paper, this too is defined to be a \emph{Key Encapsulation Method} (\texttt{KEM}).
|
||||
As an \texttt{AHBE} system eliminate the trusted dealer, the \textbf{BSetup} and \textbf{BKeyGen} step morph together, as there is no global \textbf{BSetup} step required, but merely something each user should locally run. As all other schemes defined in this paper, this too is defined to be a \emph{Key Encapsulation Method} (\texttt{KEM}).
|
||||
|
||||
\begin{description}
|
||||
\item[KeyGen$(i,n,N)$] Let $N$ be defined as the number of potential receivers of the scheme and let $n \leq N$ be defined as the maximum number of receivers of an ad-hoc broadcast recipient group. The \textbf{KeyGen} (this) algorithm is run by each user $i \in [1,N]$ to create her own public/secret key pair. A user takes $n, N$ as well as her own index $i \in [1,N]$. It's not mentioned how the user receives this index in practice, without simply having a central authority giving them this, but one could imagine the users being aware of how many recipients there are in total and simply increment this to get their own index, if one disregards the issues of people joining the peer-to-peer network at the same time. The \textbf{KeyGen} algorithm outputs the users public/secret key pair $(PK_i,SK_i)$. We define a shorthand for several users key pairs; $\{(PK_i, SK_i)\ |\ i \in S \subseteq [1,N] $ as $(PK_i,SK_i)_{S}$ and likewise only for the public keys; $(PK_i)_{S}$. All of this depends on a security parameter $\lambda$, which is implicitly given to the algorithm.
|
||||
|
|
@ -480,7 +480,7 @@ As discussed, an \AHBE scheme consist of three algorithms; \textbf{KeyGen, AHBEn
|
|||
\begin{itemize}
|
||||
\item For receiver $i \in [1,n]$, invoke the setup algorithm of the BE Scheme used by the underlying \KHBE scheme; \textbf{BSetup}, to generate a public/private key pair $(PK_i, SK_i)$ for the \KHBE scheme.
|
||||
\item Receiver $i$ runs \textbf{BKeyGen} and obtains $d_i(j) \leftarrow \mathbf{BKeyGen}(j,SK_i)$ for $j = 1,\dots,n$. The public key of the specific receiver $i$ in the \AHBE scheme is then:
|
||||
$$PK_{AHBE} = \{d_i(j) | 1 \leq i \neq j \leq n\} \cup \{PK_i\}$$ Where $PK_i$ came from the \textbf{BSetup} call.
|
||||
$$PK_{\mathtt{AHBE}} = \{d_i(j) | 1 \leq i \neq j \leq n\} \cup \{PK_i\}$$ Where $PK_i$ came from the \textbf{BSetup} call.
|
||||
\item The private key of receiver $i$ is then set to be the \emph{unpublished} $d_i(i)$.
|
||||
\end{itemize}
|
||||
\item[AHBEnc] Computes the header and key for a receiver set $S$ in the following way:
|
||||
|
|
@ -505,7 +505,7 @@ $$k = \mathbf{BDec}(S, i, d(i), Hdr, K) $$
|
|||
The security of the \AHBE scheme is proven by a reduction to the underlying \KHBE scheme. As such, if the underlying \KHBE scheme is presumed to be secure, so should the \AHBE scheme. Furthermore, the \AHBE scheme has semi-static security, if the \KHBE scheme has adaptive security.
|
||||
|
||||
\begin{theorem}
|
||||
The generic \AHBE scheme has semi-static security if the underlying \KHBE scheme has adaptive security.
|
||||
The generic \AHBE scheme has Semi-Static security if the underlying \KHBE scheme has Adaptive security.
|
||||
\end{theorem}
|
||||
|
||||
\begin{proof}
|
||||
|
|
@ -550,7 +550,7 @@ To remedy this, we considered primarily one thing; Adding another homomorphic pr
|
|||
\begin{definition}
|
||||
If $\hdr^*$ is a header for $k_{i^*}$ under $(i^*, PK_{i^*})$, then it can be transformed into a header under $(S^*, PK)$ such that the aggregated public keys for the users within $S^*$ equals $PK$ and $i^* \in S^*$, where the underlying key is allowed to change.
|
||||
\end{definition}
|
||||
The property stated ion \textbf{Definition 2} would allow \adv{B} to challenge for a header for a receiver set only containing $i^*$, which means he does not have to worry about querying for the decryption keys of the other receivers within $S^*$. When \adv{B} receives the challenge header from the challenger, this can be transformed into a proper header for the adversary \adv{A}.
|
||||
The property stated in \textbf{Definition 2} would allow \adv{B} to challenge for a header for a receiver set only containing $i^*$, which means he does not have to worry about querying for the decryption keys of the other receivers within $S^*$. When \adv{B} receives the challenge header from the challenger, this can be transformed into a proper header for the adversary \adv{A}.
|
||||
This transformation would have to be both randomised and one-way, as otherwise the following attacks could take place;
|
||||
|
||||
\begin{description}
|
||||
|
|
@ -567,7 +567,7 @@ We will describe a game where this homomorphic operation operation breaks the se
|
|||
|
||||
\subsection{An \AHBE Implementation}
|
||||
\label{sec:AHBEImpl}
|
||||
To achieve a Semi-Static secure \AHBE scheme, we first need to produce an adaptively secure \texttt{BE} scheme which is key homomorphic. To this end, we use the scheme defined in \ref{sec:BE} coupled with the generic transformation from Semi-Static to Adaptive by Gentry and Waters \cite{GentryWaters}. Note that $g, h_{i,s} \text{ for } i \in [1,n], s \in \{0,1\}$ be independent generators of a group $\mathbb{G}$ of prime order $p$, with a bilinear map $e : \Gm \times \Gm \ra \Gm_{T}$.
|
||||
To achieve a Semi-Static secure \AHBE scheme, we first need to produce an Adaptively secure \texttt{BE} scheme which is key homomorphic. To this end, we use the scheme defined in Section \ref{sec:BE} coupled with the generic transformation from Semi-Static to Adaptive by Gentry and Waters \cite{GentryWaters}. Note that $g, h_{i,s} \text{ for } i \in [1,n]$ and $ s \in \{0,1\}$ are independent generators of a group $\mathbb{G}$ of prime order $p$, with a bilinear map $e : \Gm \times \Gm \ra \Gm_{T}$.
|
||||
|
||||
We define all algoritms prefixed by \texttt{AB} to be an \emph{adaptively secure} \texttt{BE} algorithm.
|
||||
\begin{description}
|
||||
|
|
@ -624,6 +624,9 @@ We note, that it is not obvious if the value of all the different $\alpha$'s can
|
|||
|
||||
As such, we conclude that, if there is a reduction to be found from the \AHBE instantiation directly to the BDHE problem, then we were not to find this.
|
||||
|
||||
\section{Conclusion}
|
||||
We have argued for the necessity of extensions to Public Key Cryptography, specifically those of Identity Based Encryption, Broadcast Encryption, Threshold Public Key Encryption and Ad-Hoc Broadcast Encryption. For each of these extensions, we have presented the model of the schemes, what is used to define the security of the schemes as well as an actual construction. By reading papers in which these schemes were originally presented, we have encountered multiple typos and errors which in the best case can be easily fixed thus making the proofs legitimate, but in the worst case can not be salvaged. One of these cases, which is the one we have primarily focused on, is that of Ad-Hoc Broadcast Encryption. In the main paper regarding this scheme, their reduction proving the security of their model does not hold, as they do not account for some missing decryption keys. We have attempted to fix this, by extending their definition of a Key Homomorphic Broadcast Encryption scheme, but by adding a property which would make the the original reduction work, we cause another security flaw, which is naturally not desirable. Furthermore, we attempt to prove their instantiation of an \AHBE scheme secure by imagining an adversary of their instantiation and then attempting to solve the BDHE-problem. This was however not succesful either and we conclude that this scheme and their transformation likely will not be salvageable.
|
||||
|
||||
|
||||
\newpage\bibliographystyle{plain}
|
||||
\nocite{*}
|
||||
|
|
|
|||
Loading…
Reference in New Issue