-
Notifications
You must be signed in to change notification settings - Fork 9
PGP Posting Threat Model
This threat model focuses on the new threats exposed by extending the [Plain Post posting threat model](Plain Posts Posting Threat Model). For a complete picture of the threats introduced by PGP, you should also see the [PGP Post Reading Threat Model](PGP Post Reading Threat Model).
PGP is a Privly Application facilitating the injection of encrypted and authenticated content on any website. The application is loaded locally as part of a browser extension and plugin (available for Google Chrome and Mozilla Firefox) and communicates to an untrusted content server over HTTPS. An untrusted key server allows for seamless authenticated public key discovery. For a more detailed outline of the protocol, see the protocol document.
- Daniel Reichert, PGP App Developer.
Contributors welcome!
- Version 0.1DRAFT (Current): First draft.
- Security Objectives
- Application Overview
- Application Decomposition
- Threats
- Vulnerabilities
The security objectives are:
- Limit content access to those specified during content creation, identified by public keys.
- Prevent the host page from accessing the content.
- Allow users to destroy, update, and share content after emailing or sharing it on the internet.
- Authenticate identity from proof of ownership of an email.
It is worth noting that our security objectives do not include:
- Anonymizing the connections and identities of users.
- Protecting against key-loggers and other similar malware and backdoors on the client's machine.
- Hiding metadata of signed messages
Posting New Content
This process is for generating a new Privly-type link directly from the extension.
- (a) The user initiates the posting process and types content into the PGP application.
- (b) The PGP application encrypts the message sends the ciphertext to the content server.
- (c) The content server returns the content URL to the PGP application.
- (d) The PGP application passes the content URL onto the extension.
- (e) The extension places the content URL into the host page.
____________ ____________________________________________
| | | |
| Host Page | | Extension |
| | <---Content URL---< | |
|____________| |__________________________________________|
^
Content URL
|
____________ _____________________|______________________
| | | |
| User | >--User Content---> | PGP App |
| | | |
|____________| |__________________________________________|
| /\
Ciphertext Content URL
\/ |
___________________________________________
| |
| Content Server |
| |
|__________________________________________|
Extension scenarios are:
- Receiving Content URLs from PGP Application
- Posting Content URLs to host pages
PGP Application Scenarios are
- Accept user input for new content
- Sending ciphertext to content servers
- Receiving Content URLs from Content Server
Content Server scenarios are
- Authenticate identity of person using the PGP application
- Accept content from PGP application
- Send content URL to PGP Application
Host Page Scenarios are
- Accept the content URL from the extension
- Extension: JavaScript, HTML, CSS.
- PGP App: JavaScript, HTML, CSS, jQuery, select2, openPGP.js, localforage.
- Content Server: Any server capable of serving files over SSL.
- Host Page: Any web standard application.
The most important application security mechanisms known at this time are:
- Giving the host page a link to the ciphertext instead of the content itself
- All messages uploaded to the server are encrypted and signed with the correct public key(s)
This section describes the trust boundaries, entry points, exit points, and data flows.
- The PGP application assumes the openPGP.js library performs cryptographic operations faithfully.
- The content server trusts user content authenticated via session cookies.
- The PGP application trusts the content URL given by the content server over SSL.
- The extension trusts the content URL given by the PGP application.
- The host page trusts the content URL given by the extension's script.
- Port 443 for HTTPS.
- User login. Users login to a content server using any form of authentication supported by the content server. The user then has an authentication cookie tied to the content server's domain and all requests can be authenticated from the PGP applications.
- Typing content. Users type their content directly into the PGP application. User's trust the identity and security of the application because it is served locally from the extension and is not tied to a remote domain.
- Posting content to the content server. When the user submits the PGP application, the content is encrypted and signed, then the ciphertext is transmitted to the content server over SSL.
- Returning the content URL. The content server returns the URL for the content to the injectable application over SSL. The content url conforms to the URL Specification, but additional parameters and tokens may be added depending on the authorization requirements for the content. Generally a content server will want to add a content access token to the URL so old links to the same content can easily be expired.
In the application overview, points a, b, c, d, and e delineate possible points of attack.
Attacks will be judged according to the DREAD model:
- Damage: How big would the damage be if the attack succeeded?
- Reproducibility: How easy is it to reproduce an attack?
- Exploitability: How much time, effort, and expertise is needed to exploit the threat?
- Affected Users: If a threat were exploited, what percentage of users would be affected?
- Discoverability: How easy is it for an attacker to discover this threat?
Each category has a minimum score of 0 and a maximum score of 10. The final DREAD score is the average of the category scores: (D + R + E + A + D) / 5.
Threat Description: Users with little technical knowledge may be fooled by a phishing website or plugin posing as the legitimate Privly PGP application.
- Damage: A user could be compelled to use the phishing application to post their private content. Score: 10
- Reproducibility: Users with little technical expertise may be susceptible if they visit a website that mimics the behavior of the legitimate Privly PGP application. Score: 6
- Exploitability: Exploitability depends on the user. The extensibility of the system provides avenues for providing users with false yet plausible information about "advances" in the system. This threat can be mitigated by effective user education and communication. Score: 7
- Affected Users: Users are affected individually; however, information they reveal to the phishing website may endanger others. Score: 5
- Discoverability: It's unknown how the notion of discoverability may be measured for this threat. Score: N/A
Threat Description: The user could be made to download a malicious version of the Privly Client instead of the legitimate version. The malicious version could contain backdoors.
- Damage: A compromised client could lead to the compromise of all posts sent by the user, and allow for further monitoring of the user's behavior. Score: 10
- Reproducibility: Due to Chrome's use of SSL with HSTS and certificate pinning, reproducing this on Chrome is unlikely. Under Firefox, integrity checks are also very feasible. Score: 3
- Exploitability: A highly considerable amount of time, effort and expertise is required for this threat to be pulled off remotely. Score: 3
- Affected Users: Depending on the malicious actor, a single user could be targeted (if the actor is a hacker connected to a LAN) or an entire nation (if the hacker is an ISP being controlled by a malicious government.) Score: 5
- Discoverability: In the majority of cases, this threat requires extensive testing of the SSL and code delivery infrastructure. Score: 3
Threat Description: The content server's SSL certificate, used for authentication, could be man-in-the-middled via a Certificate Authority compromise or other means.
- Damage: The attacker would be able to intercept, read and modify the stream of communications sent to and from the client. Since message content is encrypted and signed locally before being sent to the server, the damage is limited to metadata. Score: 5
- Reproducibility: Measures such as HSTS, responsible CA delegation and certificate pinning in browsers make this threat difficult to reproduce. Score: 3
- Exploitability: A highly considerable amount of time, effort and expertise is required for this threat to be pulled off remotely. Score: 3
- Affected Users: Depending on the malicious actor, a single user could be targeted (if the actor is a hacker connected to a LAN) or an entire nation (if the hacker is an ISP being controlled by a malicious government.) Score: 5
- Discoverability: Depending on the Certificate Authority's operational security, the ability to control the Certificate Authority to forge certificates may be extremely easy to very difficult. Cases such as DigiNotar and even VeriSign have made this a real threat, however, even with trusted Certificate Authorities. Score: 6
Threat Description: The content server storing the ciphertext is compromised by a third party.
- Damage: The attacker could delete all posts. If the user continues to use the content server connection information could also be compromised Score: 8
- Reproducibility: The possibility of a full remote compromise of a content server is unknown and ambiguous. Score: 5
- Exploitability: Breaking into a server requires significant knowledge and skill, including obtaining a security hole either in the server's software (SSHD, HTTPD, etc.) or in the human security factors governing the server. Score: 3
- Affected Users: Everyone connecting to the content server is under the realm of being possibly affected. Score: 9
- Discoverability: Threat requires extensive penetration testing in order to discover if it potentially exists. Score: 2
Same as Point (B).
No known threats when the application is packaged with the extension.
Threat Description: The host page refuses the link.
- Damage: The user is not able to use the site or service with Privly. Score: 2
- Reproducibility: Any web application could add form validation Javascript that would reject certain host domains. Score: 8
- Exploitability: Host sites are more concerned with keeping users on their web site than they are about owning all the content shown on their websites. A site is more likely to not accept any user submitted hyperlinks than it is to selectively refuse hyperlinks. Many moderation platforms will automatically flag domains based on user behavior as being SPAM. Tying the content server to a particular domain is more likely to result in page refusal. Score: 3
- Affected Users: Everyone posting Privly-type content to the refusing host page is affected. Score: 5
- Discoverability: Discoverability for this threat is ill defined. Score: N/A
Threat Description: The host page receiving the content (usually a social network or an email), could be compromised so an adversary would have access to all the links posted by the user.
- Damage: The content is encrypted locally, so no content is compromised. Score: 0
- Reproducibility: The possibility of a full remote compromise of a host page is unknown and ambiguous. Score: 5
- Exploitability: Breaking into a server requires significant knowledge and skill, including obtaining a security hole either in the server's software (SSHD, HTTPD, etc.) or in the human security factors governing the server. Score: 3
- Affected Users: Everyone posting content to the host page could possibly be affected, but users do not post to all host sites so fewer users are affected than the content server being compromised. Score: 4
- Discoverability: Threat requires extensive penetration testing in order to discover if it potentially exists. Score: 2
[PGP Reading Threat Model](PGP Reading Threat Model)
No vulnerabilities have been formally identified. Please contribute to this section!
Adapted from Cryptocat's Threat Model
Foundation Home
Repository List
Development Mailing List
Testing Mailing List
Announcement Mailing List
Central Wiki
Submit a Bug
IRC
Download Extension
These documents are under active development and discussion.
Credit: This Google Summer of Code content is licensed under the CC Attribution-Noncommercial-Share Alike 3.0 Unported license furnished by the Sahana Software Foundation.