|
|
@@ -0,0 +1,45 @@
|
|
|
+In the threat model of Hybrid 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 were possible. However, other dangers such as identification by the service provider or manipulation of data must also be analyzed.
|
|
|
+
|
|
|
+\subsection{Service Provider – Twitter}
|
|
|
+\label{sec:threat-model-service-provider}
|
|
|
+Hybrid OSN users can be easily identified by the service provider Twitter, even if they only use Hybrid OSN passively to read private tweets of other users and do not write private tweets themselves.
|
|
|
+
|
|
|
+For using the Twitter 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 API. When logging in on Hybrid 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 API on their own. The obtained app token could then be stored in the Hybrid OSN app, and the use of the application could be obscured. In this case, the identification possibility via the Hybrid OSN app token is omitted, and the passive use would be possible without danger.
|
|
|
+
|
|
|
+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 OSN user.
|
|
|
+
|
|
|
+\subsection{Gun}
|
|
|
+\label{sec:threat-model-gun}
|
|
|
+In Hybrid OSN, Gun takes the role of a database shared by the peers. The dashboard also establishes a direct connection. The data is publicly accessible and editable.
|
|
|
+
|
|
|
+The stored data is a combination of hashtag and timestamp, which serve as information for the trends in the Hybrid OSN dashboard. For every private tweet of a user, there is an entry consisting of Twitter user id, 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 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 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{IPFS}
|
|
|
+\label{sec:threat-model-ipfs}
|
|
|
+Since IPFS is publicly accessible, anyone can add and retrieve data. However, it is not possible to change or delete data. A hash of the content addresses the data stored in 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 IPFS is therefore impossible. The encrypted data also does not contain any clues that allow conclusions to be drawn about Hybrid OSN.
|
|
|
+
|
|
|
+In combination with the publicly available information from Gun, all private tweet data could be found in IPFS. However, because of the encryption of the content, the data is worthless.
|
|
|
+
|
|
|
+Due to the decentralization of the system, the availability of 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 is 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 for each user. With symmetric encryption, only one key is used, which is stored in the source code of Hybrid OSN. In this way, only the Hybrid 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 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 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. Only accepted followers should then be able to read public and private tweets. A non-approved twitter user is still able to fetch the encrypted private tweets from 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.
|
