solution-strategy-architecture.tex 6.5 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117
  1. Various models can be used to implement a secure data exchange between the users of an \ac{OSN} via additional network. The solution strategies shown below differ primarily in the question of where data are stored and how it can be found.
  2. \begin{figure}[h!]
  3. \centering
  4. \begin{subfigure}[c]{0.32\textwidth}
  5. \includegraphics[width=\textwidth]{solution-architecture-a}
  6. \caption{}
  7. \label{fig:solution-architecture-a}
  8. \end{subfigure}
  9. \begin{subfigure}[c]{0.32\textwidth}
  10. \includegraphics[width=\textwidth]{solution-architecture-b}
  11. \caption{}
  12. \label{fig:solution-architecture-b}
  13. \end{subfigure}
  14. \begin{subfigure}[c]{0.32\textwidth}
  15. \includegraphics[width=\textwidth]{solution-architecture-c}
  16. \caption{}
  17. \label{fig:solution-architecture-c}
  18. \end{subfigure}
  19. \caption{Architectures for secure data exchange among users: (a) by the use of an additional server, (b) via a \ac{P2P} network connecting all users or (c) via a hybrid \ac{P2P} network with servers acting as super-peers.}
  20. \label{fig:solution-architecture}
  21. \end{figure}
  22. One possibility is to use an extra infrastructure to store the data, as shown in Figure \ref{fig:solution-architecture-a}. An additional server stores and distributes the private data to be protected. Using a server has the advantage that the data are always available and there are no dependencies to other hybrid \ac{OSN} users. Furthermore, resources only have to be available centrally and not locally on the user's device. At the central location, the data can be indexed and explicitly queried. However, the operation and maintenance of one or more servers are problematic. In principle, the question for the service provider has to be clarified, because the reliability of the infrastructure is essential. FaceCloak (see Chapter \ref{sec:facecloak}) used an architecture based on this structure.
  23. Instead of operating a separate, additional server, it would also be possible to use a third-party, existing infrastructure. These include, for example, blockchains or \ac{P2P} file-sharing networks that could be used for data exchange. Since no influence can be exerted on existing infrastructure, its use entails further restrictions and potential risks.
  24. A decentralized solution strategy would create a network among users of the hybrid application (see Figure \ref{fig:solution-architecture-b}). No extra infrastructure would have to be operated. The users would then have a typical peer role. By using this model, it is difficult to keep data available and accessible even if the user is permanently or temporarily offline. The problem needs to be solved.
  25. Furthermore, the resources on the devices are limited, so that effective and economical solutions are needed. Another challenge is the addressing of peers. Since they typically do not have a static \ac{IP} address, solutions have to be found for accessibility. Since there is no central, global index, finding data is even more difficult.
  26. Adding servers to the \ac{P2P} network would create a hybrid solution (see Figure \ref{fig:solution-architecture-c}). In this model, the servers would take on the role of a super peer, permanently reachable at a fixed address, thus stabilizing the \ac{P2P} network. The problem of data availability could be limited by storing much of the data at super peers. The problem of addressing would also be solved by establishing connections to other peers via the known super peers. However, the problem would remain with the cost and maintenance of the servers.
  27. Table \ref{tab:solution-strategy-architecture-comparison} lists the advantages and disadvantages of the different strategies for the hybrid \ac{OSN} architecture.
  28. % Own infrastructure
  29. \newcommand{\advantageoi}{\begin{minipage} [t] {0.3\textwidth}
  30. \begin{itemize}
  31. \item Availability of data
  32. \item Finding the data
  33. \item Resources only have to be available centrally
  34. \item No dependencies among hybrid \ac{OSN} users
  35. \end{itemize}
  36. \hspace{1mm}
  37. \end{minipage}}
  38. \newcommand{\disadvantageoi}{\begin{minipage} [t] {0.3\textwidth}
  39. \begin{itemize}
  40. \item Expenses
  41. \item Who operates the infrastructure?
  42. \item Compliance with legal requirements
  43. \end{itemize}
  44. \end{minipage}}
  45. % Own network
  46. \newcommand{\advantageon}{\begin{minipage} [t] {0.3\textwidth}
  47. \begin{itemize}
  48. \item Resources scale with increasing number of users
  49. \end{itemize}
  50. \end{minipage}}
  51. \newcommand{\disadvantageon}{\begin{minipage} [t] {0.3\textwidth}
  52. \begin{itemize}
  53. \item Availability of data
  54. \item Finding the data
  55. \item Addressing the peers
  56. \item Local resources limited
  57. \end{itemize}
  58. \hspace{1mm}
  59. \end{minipage}}
  60. % Hybrid solution
  61. \newcommand{\advantagehn}{\begin{minipage} [t] {0.3\textwidth}
  62. \begin{itemize}
  63. \item Availability of data
  64. \item Peer discovery
  65. \end{itemize}
  66. \end{minipage}}
  67. \newcommand{\disadvantagehn}{\begin{minipage} [t] {0.3\textwidth}
  68. \begin{itemize}
  69. \item Expenses
  70. \item Who operates the infrastructure?
  71. \item Finding the data
  72. \end{itemize}
  73. \hspace{1mm}
  74. \end{minipage}}
  75. % External infrastructure
  76. \newcommand{\advantageei}{\begin{minipage} [t] {0.3\textwidth}
  77. \begin{itemize}
  78. \item Ideally no costs
  79. \item Resources are provided by the external infrastructure
  80. \end{itemize}
  81. \end{minipage}}
  82. \newcommand{\disadvantageei}{\begin{minipage} [t] {0.3\textwidth}
  83. \begin{itemize}
  84. \item No influence on future development
  85. \item Dependence on infrastructure entails risks
  86. \end{itemize}
  87. \hspace{1mm}
  88. \end{minipage}}
  89. \begin{table}[h!]
  90. \centering
  91. \begin{tabularx}{\textwidth}{X|l|l|}
  92. \cline{2-3}
  93. & \textbf{Advantages} & \textbf{Disadvantages} \\ \hline
  94. \multicolumn{1}{|l|}{\textbf{\begin{tabular}[c]{@{}l@{}}Own infrastructure\\ (centralized)\end{tabular}}} & \advantageoi & \disadvantageoi \\ \hline
  95. \multicolumn{1}{|l|}{\textbf{\begin{tabular}[c]{@{}l@{}}\ac{P2P} network\\ (decentralized)\end{tabular}}} & \advantageon & \disadvantageon \\ \hline
  96. \multicolumn{1}{|l|}{\textbf{\begin{tabular}[c]{@{}l@{}}Hybrid \ac{P2P} network\\ (decentralized)\end{tabular}}} & \advantagehn & \disadvantagehn \\ \hline
  97. \multicolumn{1}{|l|}{\textbf{External infrastructure}} & \advantageei & \disadvantageei \\ \hline
  98. \end{tabularx}
  99. \caption{Advantages and disadvantages of the different solution strategies for the hybrid \ac{OSN} architecture.}
  100. \label{tab:solution-strategy-architecture-comparison}
  101. \end{table}