|
|
@@ -1,4 +1,4 @@
|
|
|
-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 were possible. However, other dangers such as identification by the service provider or manipulation of data must be analyzed.
|
|
|
+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}
|
|
|
@@ -10,29 +10,29 @@ So far not implemented, but theoretically possible is that each user creates an
|
|
|
|
|
|
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}
|
|
|
+\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 is publicly accessible and editable.
|
|
|
+In Hybrid \ac{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 \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.
|
|
|
+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 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.
|
|
|
+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{\ac{IPFS}}
|
|
|
\label{sec:threat-model-ipfs}
|
|
|
Since \ac{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 \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}. However, because of the encryption of the content, the data is worthless.
|
|
|
+In combination with the publicly available information from GUN, all private tweet data could be found in \ac{IPFS}. However, because of the encryption of the content, the data is 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 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, 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.
|
|
|
+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.
|
|
|
|
