ekyc

3.security.tex (8173B)

---

 \chapter{Security}
 
 \section{Cryptography}
 
 The security of this application is contingent upon the implementation of cryptographic primitives.
 In this instance, we will utilise the robust \textbf{libsodium} library.
 
 The first primitive employed is the hashing of passwords utilising Argon2id, which is particularly
 slow and therefore mitigates brute-force offline attacks.
 The result of this process, along with the salt and algorithm used, is encoded according to
 the standard PHC string format.
 
 \begin{bfhWarnBox}
 The slowness of Argon2id provides protection against offline attacks, but it is necessary to implement additional protection against online brute force attacks. 
 The number of attempts over a period of time must therefore be limited.
 \end{bfhWarnBox}
 
 The second primitive used is an AEAD (authenticated encryption with additional data), which is used
 to seal contextual data injected into an HTML form in order to implement workflow
 (succession of forms + navigation).
 
 \begin{bfhNoteBox}
 The AEAD used to create a crypto token utility to convey information between forms.
 The implementation is analogous to that of Branca \cite{Branca}.
 \end{bfhNoteBox}
 
 The last primitive employed is the \gls{CSPRNG} generator, which is used to generate non-guessable random code.
 
 \section{OAuth2 Framework} \label{OAuth2-Framework}
 
 This project takes place in the context of the OAuth2 framework, which defines a model
 (notably for security) as well as a set of protections required to comply
 with the standard \cite{rfc6749}. OAuth2 allows a third-party application (client) to access a set of resources (scope)
 belonging to a resource owner (RO) on a remote server.
 
 OAuth2 defines 4 roles:
 \begin{table}[H]
     \centering
     \setupBfhTabular
     \begin{tabular}{llp{.58\textwidth}}
     \rowcolor{BFH-tablehead}
     \textbf{Role}&\textbf{Type}&\textbf{Description}\\\hline
     Resource             & Data    & The resource in question is to be accessed. In KYCID its an human identity \\\hline
     Resource owner (RO)  & Person  & Customer in KYCID. He own his ID                                           \\\hline
     Client               & Machine & Third party should perform and delegate to KYCID an eKYC process.          \\\hline
     Authorization server & Machine & OAuth2 server. it's KYCID.\\\hline
     Resource server      & Machine & Server provide resource access. it's KYCID.\\\hline
     \end{tabular}
     \caption{Roles in OAuth2 Framework}
 \end{table}
 
 To describe the different security features, we first need to describe the different steps in an authorisation flow sequence, as shown in the figure below:
 \begin{figure}[H]
     \centering
     \includegraphics[width=.95\textwidth]{oauth2-flow}
     \caption{OAuth2 authorization flow sequence}
     \label{fig:OAuth2-flow}
 \end{figure}
 
 The figure above shows a sequence of steps in an authorisation code flow. The steps are explained below:
 
 \begin{enumerate}
     \item the resource owner initiates the flow.
     \item the client redirects the user via the HTTP redirection mechanism. However, the client is susceptible to a \gls{CSRF} attack due to the fact that initialising the flow is merely a URL to which the user is redirected. This URL is therefore susceptible to guessing, and therefore the attack can be carried out (see section \ref{csrf}).
     \item The RO interacts with the authorization server in a front channel call phase due to the presence of a web app that allows interaction.
 
     In this case, it is the authorization server that is vulnerable to the RO attempting to circumvent the established procedures. Consequently, it is imperative to never trust any input originating from the user (systematic validation) and to implement measures to protect against CSRF (see section \ref{csrf}).
 
     The purpose of server authorisation is to determine whether to grant access to the requested resource (scopes). To achieve this, the server can implement any application logic (within the web app) to perform this action.
 
     \item If the previous step has been authorised, the RO will be redirected to the client with an authorisation code and the csrf protection token from step 2 (this information is conveyed by query parameters called \textit{code} and \textit{state}).
 
     With this code we can make a so-called back channel request (as opposed to the front channel of step 3), because it is an http request from server to server and therefore there is no WebUI. This request is sent from the client to the authentication server with the received authentication code and something that authenticates the client to the authentication server (see section \ref{client-authn}).
 
     This request retrieves an access token. The reason for having 2 tokens (authorisation code and access token) instead of a direct access token is related to the fact that the token returned by the front channel can only be passed in url (query parameter), which is not a secure means of transport for information as sensitive as an access token, as url can be logged in several places (proxy server, cache, history, intercepted by the application on Android, log server). Therefore, the authorisation code can only be used once to obtain the access token.
 \end{enumerate}
 
 \section{Cross-site request forgery} \label{csrf}
 
 A CSRF attack may occur when an application contains actions that are linked to one another. It is possible for another site to forge a request for a given action, thus bypassing the intended steps and processes. This could result in the hijacking of the originally planned process by a hacker. Additionally, the request could be made on another site, leading to the recovery of the cookie at the time of the request.
 To mitigate this issue, two methods can be employed:
 
 The first method involves setting the "Same-Site" attribute to "Lax" on the cookie. This prevents the cookie from being added if the request is made on another site or domain. This avoids recovering the session.
 
 The second method is to add a CSRF token (which must not be forgeable anywhere other than on the server) in a hidden field. When the request is processed, the token is checked to ensure its validity. In KYCID, the CSRF token is implemented by an AEAD (see section A), which encrypts the contextual data of the action, thus securing it. In addition, the action and session are used as additional data to ensure that the AEAD signature is unique for each action and session, thus avoiding reusing a token twice. Furthermore, the token has a defined lifetime.
 
 \section{Client authentification} \label{client-authn}
 
 Two methods exist for authenticating the client. The first and simplest method involves recording a secret that is known only to the client and the authorisation server. By sending this secret, the authorisation server can verify the client's authenticity.
 
 However, this method can cause problems in the event of a leak or if the client is not executed on a server but directly in JavaScript in the browser or in an application on a smartphone. This is referred to as a non-confidential client. This client is unable to safeguard this secret.
 
 In response to this problem, OAuth2 has introduced a second method of client authentication called PKCE (Proof Key for Code Exchange) which does not authenticate the client but rather authenticates that the Back Channel request was made by the same instance as the Front Channel request. To achieve this, the client generates a secret, named \textit{code\_verifier}, at random and hashes it with SHA256. The result of this process is called \textit{code\_challenge}. The authentication server is able to verify the authenticity of the client by repeating the process of hashing the \textit{code\_verifier} and comparing the result with the \textit{code\_challenge} sent in the front-channel request.
 
 \begin{bfhWarnBox}
 In OAuth 2.1, it is imperative to utilise PKCE, regardless of whether the client possesses a secret. This is to mitigate the risk of an attack in the event of a leak of this secret.
 \end{bfhWarnBox}
 
 \begin{bfhNoteBox}
 In the field of cryptography, PKCE represents a commitment scheme.
 \end{bfhNoteBox}