71 lines
7.2 KiB
TeX
71 lines
7.2 KiB
TeX
\documentclass{article}
|
||
\usepackage{bm}
|
||
\usepackage{amsmath}
|
||
\usepackage{graphicx}
|
||
\usepackage{amsfonts}
|
||
\usepackage{newpxtext,newpxmath}
|
||
\usepackage{scrextend}
|
||
\usepackage{seqsplit}
|
||
\usepackage[autostyle]{csquotes}
|
||
\usepackage{xspace}
|
||
|
||
\newcommand{\horrule}[1]{\rule{\linewidth}{#1}} % Create horizontal rule command with 1 argument of height
|
||
\newcommand{\ID}{\texttt{ID}\xspace}
|
||
|
||
\author{Alexander Munch-Hansen \\ 201505956}
|
||
|
||
\title{
|
||
\normalfont \normalsize
|
||
\textsc{Aarhus University} \\ [20pt] % Your university, school and/or department name(s)
|
||
\horrule{0.5pt} \\[0.4cm] % Thin top horizontal rule
|
||
\huge Beyond Public Key Cryptography \\
|
||
\large A study of various extensions of public key crypto, with focus on Broadcast Encryption schemes \\ % The assignment title
|
||
\horrule{2pt} \\[0.5cm] % Thick bottom horizontal rule
|
||
}
|
||
|
||
\date{\today}
|
||
\begin{document}
|
||
\maketitle
|
||
\section{Introduction}
|
||
By definition, \emph{Encryption} is the process of converting information into a \emph{code} with the purpose of preventing unauthorized access \cite{oxford}. Traditionally, the way this was accomplished was via some a priori established secret key $k$, which could then be used both for \emph{encryption}, but also for \emph{decryption}. This concept was then challenged by the concept of \emph{Public Key Cryptography}, which allows two parties to communicate with each other in a secure and private fashion, without having already shared the aforementioned secret key. This allowed each party to have a \emph{Public Key} and a \emph{Secret Key}, which could then be used to encrypt and decrypt, respectively. This works well and is used in many applications, such as \emph{SSH} and \emph{SSL}. It does however have one caveat. \emph{Public Key Encryption} is notoriusly slow, compared to the \emph{Symmetrical}-scheme with only a single key, but if you wish to send to several people you will need to encrypt whatever you wish to send several times, once for each party and furthermore, public key encryption is very \emph{all-or-nothing}. Either a single party can decrypt what you send and see everything, or she will not be able to decrypt and thus see nothing.
|
||
|
||
% TODO: Change slightly
|
||
However, there are cases where public-key encryption is insufficient. There is often a need to specify a decryption policy in the ciphertext and only individuals who satisfy the policy can decrypt. More generally, we may want to only give access to a function of the plaintext, depending on the decryptor’s authorization. Consider a cloud service storing encrypted images. Law enforcement may require the cloud to search for images containing a particular face. Thus, the cloud needs a restricted secret key that decrypts images that contain the target face, but reveals nothing about other images. More generally, the secret key may only reveal a function of the plaintext image, for example an image that is blurred everywhere except for the target face. Traditional public-key cryptography cannot help with such tasks.
|
||
|
||
To this end, \emph{Functional Encryption} can be adopted. Essentially, in functional encryption systems, the decryption key allows the user to learn a specific, pre-defined \emph{function} of the encrypted data, rather than necessarily the actual encrypted data, note that if this function is the \emph{Identity function}, then the system will be equivalent to regular public key encryption. In a functional encryption system for some functionality $F(\cdot, \cdot)$, an authority holding a master secret key $MSK$ can generate a secret key $sk_k$ which enables the computation of the function $F(k,\cdot)$. So given some plaintext $x$, one can compute $F(k,x)$, given only the ciphertext $c$ of $x$.
|
||
|
||
Full blown functional encryption is however quite a mouthful to implement in an efficient manner and as such there are some subclasses of it. This paper will focus on \emph{Identity Based Encryption (IBE)} and \emph{Broadcast Encryption (BE)}.
|
||
|
||
% TODO: Explain IBE intuitively
|
||
|
||
|
||
\section{Syntax and preliminaries}
|
||
\subsection{Identity-Based Encryption}
|
||
\textbf{Identity-Based Encryption.} \quad An Identity-Based encryption scheme is specified by four different algorithms, all containing some sort of randomness: \texttt{Setup, Extract, Encrypt, Decrypt}: \vspace{3mm} \\
|
||
\-\hspace{5mm}\textbf{Setup:}\quad Takes some security parameter $k$ and returns the system parameters and a master-key. These system parameters include a description of a finite message space $\mathcal{M}$ as well as a description of a finite ciphertext space $\mathcal{C}$. These parameters are known publicly, wherre the master-key is known only to the trusted authority, the so called Private Key Generator (\texttt{PKF}). \vspace{3mm} \\
|
||
\-\hspace{5mm}\textbf{Extract:}\quad Takes the system parameters, the master-key and an arbitrary \texttt{ID} $\in \{0,1\}^*$ and returns a private key $d$. \texttt{ID} is essentially any arbitrary string which will be used a public key and $d$ is the corresponding decryption key, which can be used by the owner of the \texttt{ID}. Thus, the \texttt{extract} algorithm extracts a private key from the given public key. \vspace{3mm} \\
|
||
\-\hspace{5mm}\textbf{Encrypt:}\quad Takes the system parameters, \texttt{ID}, and $M \in \mathcal{M}$. Returns some ciphertext $C \in \mathcal{C}$.\vspace{3mm} \\
|
||
\-\hspace{5mm}\textbf{Decrypt:}\quad Takes the system parameters, some private key $d$ and $C \in \mathcal{C}$. Returns the plaintext $M \in \mathcal{M}$. \vspace{3mm} \\
|
||
Naturally, these algorithms must satisfy that:
|
||
$$ \forall M \in M\ :\ \text{Decrypt}(\text{params}, C, d) = M\quad \text{where}\quad C = \text{Encrypt}(\text{params}, ID, M)$$
|
||
\vspace{3mm} \\
|
||
\textbf{Chosen Ciphertext Security.} \quad We will focus on Chosen Ciphertext Security (\texttt{IND-CPA}), as this is the standard acceptable notion of security for a public key encryption scheme \cite{security_notion}. The standard definition however, is not strong enough, as we must also require that the adversary might already know of several \texttt{ID}s and decryption keys, given by the \texttt{PKG} and these should not aid the adversary in breaking the security. We define an \emph{extraction query} to be a query which yields the decryption key for a given \ID.
|
||
|
||
% TODO: Finish this section on the security definition of IBE as well as Bilinear Maps and BDH
|
||
% TODO: Write up all of the mathematical assumptions
|
||
|
||
|
||
\section{Implementation of Schemes}
|
||
\subsection{Identity-Based Encryption}
|
||
I'll cover a basic identity based encryption scheme which illustrates a basic usage of bilinear maps as well as one way to extend the \emph{Diffie-Hellman Assumption} known from Public Key Encryption. This scheme is not secure against an adaptive chosen ciphertext attack (\texttt{IND-ID-CCA}). Note that it can be extended to cover this, but this is out of the scope of this paper.
|
||
|
||
As already mentioned, an IBE-scheme is a collection of four randomized algorithms: \texttt{Setup, Extract, Encrypt, Decrypt}. $k$ is defined to be a security parameter given to the setup algorithm and $\mathcal{G}$ is a BDH parameter generator.
|
||
\subsection{Adaptive Security in Broadcast Encryption Systems}
|
||
Written by \emph{Craig Gentry \& Brent Waters}.
|
||
|
||
|
||
\newpage\bibliographystyle{plain}
|
||
\nocite{*}
|
||
\bibliography{refs}
|
||
|
||
\end{document} |