HOSN-app/thesis/content/06-discussion/threat-model.tex

In the threat model of Hybrid \ac{OSN} the potential threats for different sub-areas are shown, and the particular risk discussed. The worst would be if private data could be decrypted and assigned to a user or if identity abuse would be possible. However, other dangers such as identification by the service provider or manipulation of data must be analyzed.

\subsection{Service Provider – Twitter}
\label{sec:threat-model-service-provider}
Hybrid \ac{OSN} users can be easily identified by the service provider Twitter, even if they only use the app passively to read private tweets of other users and do not write private tweets themselves. For using the Twitter \ac{API}, it is essential to register an app to get an app token. This app token is attached to all requests sent to the Twitter \ac{API}. When logging in on Hybrid \ac{OSN} for the first time, the user accepts to use the app to access Twitter.

So far not implemented, but theoretically possible is that each user creates an app for the use of the \ac{API} on their own. The obtained app token could then be stored in the Hybrid \ac{OSN} app, and the use of the application could be obscured. In this case, the identification possibility via the Hybrid \ac{OSN} app token is omitted, and the passive use would be possible without danger. However, the Twitter developer terms forbid the use of multiple applications for a single use case \cite{twitterXXXXdev-terms}. This restriction is primary for a single developer trying to bypass the request limits. It has to be further evaluated if this rule also applies to multiple developers with only one application each.

Active use requires a public tweet and a reference in the profile description for the distribution of the public key history. Although the contents are inconspicuous, they are still sufficient for the identification of a Hybrid \ac{OSN} user.

\subsection{GUN}
\label{sec:threat-model-gun}
In Hybrid \ac{OSN}, GUN takes the role of a database shared by the peers. The dashboard also establishes a direct connection. The data are publicly accessible and editable. The stored data are a combination of hashtag and timestamp, which serve as information for the trends in the Hybrid \ac{OSN} dashboard. For every private tweet of a user, there is an entry consisting of Twitter user id, \ac{IPFS} address hash, and timestamp. Also, there are the private likes, for which there is a counter to the tweet id. For preventing the hashtag and private tweet timestamps from connecting, the time of the hashtag timestamp is set to 00:01. The trends in the dashboard are aggregated by the day, so the exact time is not essential.

The greatest threat is that an attacker may modify or delete data. By deleting entries, private tweets would no longer be found and thus no longer displayed. Changing the \ac{IPFS} hash would mean that the data could not be found and would also not be displayed. Manipulation of the timestamp would result in private tweets being loaded at the wrong time interval when the feed is loaded and thus positioned at the wrong place. Furthermore, the timestamp in GUN is used to use the appropriate public key from the public key history for decryption. Under certain circumstances, the wrong key would be selected and the private tweet could not be decrypted.

Creating entries for private tweets does not have a significant effect because the associated content stored in \ac{IPFS} must be encrypted with the private key, which is unknown to a third party. Adding wrong or modifying existing hashtag entries for trend detection is also possible and poses a significant risk as it allows manipulation of the trends. Ultimately, it is not possible to verify which hashtags were used and how often. The same applies to private likes. Since in this case the complete information is stored in GUN and can be changed, it is not possible to determine whether data has been manipulated.

\subsection{\ac{IPFS}}
\label{sec:threat-model-ipfs}
Since \ac{IPFS} is publicly accessible, anyone can add and retrieve data. Though, it is not possible to change or delete data. A hash of the content addresses the data stored in \ac{IPFS}. Since the content is entirely unknown (especially by encrypting the plaintext content), it is not possible to conclude the hash. A targeted search for private data in \ac{IPFS} is therefore impossible. The encrypted data also does not contain any clues that allow conclusions to be drawn about Hybrid \ac{OSN}. In combination with the publicly available information from GUN, all private tweet data could be found in \ac{IPFS}. But, because of the encryption of the content, the data are worthless.

Due to the decentralization of the system, the availability of \ac{IPFS} is always guaranteed. However, only as long as there are peers who make the service possible. If a peer leaves the network, its data are also lost if not reproduced beforehand. Therefore, there is no guarantee for the permanent availability of data.

\subsection{Encryption – Leakage of Keys}
\label{sec:threat-model-encryption}
On the one hand, the public key history is symmetrically encrypted; on the other hand, the private tweets are asymmetrically encrypted. The keys for asymmetric encryption are generated independently by each user and are therefore individual. With symmetric encryption, just one key is used, which is stored in the source code of Hybrid \ac{OSN}. In this way, only the Hybrid \ac{OSN} app can decrypt the public key history of a user and therefore decrypt its private tweets.

Disclosure of the source code would reveal the symmetric key. The service provider would then have all the necessary information and access to all data to read private tweets and assign them to users.

\subsection{Authorized Access}
\label{sec:threat-model-authorized-access}
A user's private tweets should be readable by all users who can also read the public tweets - except for the service provider Twitter. Therefore, a user posts the \ac{IPFS} hash that leads to the public key history on his timeline. There is a threat that authorized users may create a copy of the decrypted public key history and pass it on to third parties. Since the data in \ac{IPFS} is permanent and therefore not erasable, it can be decrypted at any time later with the appropriate public key.

If a user decides to change his profile to \enquote{private} in the account settings, the profile will no longer be publicly accessible. Solely accepted followers should then be able to read public and private tweets. A non-approved user is still able to fetch the encrypted private tweets from \ac{IPFS}. However, since the link to the public key history is no longer accessible, the private tweets decryption is not possible. If non-approved users or third parties already have the link to or a backup of the public key history from the past, all private tweets of the past can still be decrypted. Whenever a profile is changed to \enquote{private} a new pair of keys should be generated to ensure that future private tweets are only readable to approved users. Otherwise the latest key is still valid and could be used to encrypt future private tweets.