Patterns
- Active Warnings
- Attractive Options
- Complete Delete
- Conveying Threats & Consequences
- Create a Security Lexicon
- Create Keys When Needed
- Delayed Unrecoverable Action
- Detailed Notifications About Security
- Direct Access to UI Components
- Disable by Default
- Disable of Services
- Disclose Significant Deviations
- Distinguish Between Run and Open
- Distinguish Internal Senders
- Distinguish Security Levels
- Email-Based Identification and Authentication
- Explicit Item Delete
- Explicit User Audit
- Failing Safely
- General Notifications About Security
- Immediate Notifications
- Immediate Options
- Indirect Access to UI Components
- Informative Dialogues
- Install Before Execute
- Key Continuity Management
- Levels of Severity
- Leverage Existing Identification
- Localization of Specific Areas
- Migrate and Backup Keys
- Noticeable Contextual Indicators
- Providing Recommendations
- Quick Description of UI Components
- Redundant Notifications
- Reset to Installation
- Restricted Areas Notification
- Security Features Used by the System
- Security Features Used by the User
- Send S/MIME-Signed Email
- Separating Content
- Sequential Access to UI Components
- Suggestive Dialogues
- System’s Security Tasks
- The Absence of Indicators
- Track Received Keys
- Track Recipients
- Warn When Unsafe
Patterns are based on scientific sources.
Usable Security Pattern - Send S/MIME-Signed Email
Luigi Lo Iacono, Peter Nehren
January 18, 2016
Send S/MIME-Signed Email
| Name | Send S/MIME-Signed Email |
| Sources | (Garfinkel, 2005) |
| Synonyms | None |
| Context | S/MIME signatures provide sender authentication which can be useful protection against spam and “phishing” attacks. Today’s most widely used mail clients support S/MIME signatures; programs that do not support S/MIME do not have significant usability problems when they receive signed mail. |
| Problem | How to authenticate email senders? |
| Solution | Send email signed with S/MIME signatures to increase confidence in email, allow recipients to detect mail with forged From: headers, increase familiarity with secure email through causal exposure and the resulting “passive learning”, and give web-mail providers incentive to support S/MIME. |
| Examples | Amazon.com sends digitally signed VAT invoices to its merchants in Europe.  Source: (Garfinkel, 2005) |
| Implementation | Start with messages that are automatically-generated and sent with “do-not-reply” return addresses. Obtain a Digital ID from VeriSign or Thawte; use it with OpenSSL to write S/MIME signatures on all messages that are sent out automatically. Renew the key every year. Additional usability can be obtained by maintaining a database of the email client used by each user and only sending S/MIME-signed mail to those users who have support for S/MIME. Companies that receive email from customers can determine mail clients by examining the headers of incoming customer e-mail. Mail programs such as Outlook Express should not offer to send signed mail unless they can deliver on the promise—that is, unless the user has obtained and installed a Digital ID. |
| Consequences | S/MIME Digital ID’s for organizations sending signed mail will be distributed, allowing them to receive mail that is sealed with cryptography from their customers. Some mail systems damage signed messages; these systems will only be fixed if they are exercised and the bugs are found. |
| Dependencies | None |
| Relationships | [Track Recipients] [Key Continuity Management] [Create Keys When Needed] |
| Principles | [Indentifiablity] |
| Guidelines | None |
| Check lists | None |
| Use cases | None |
| Tags | Send S/MIME-Signed Email, Email, Authentication, Identification, Integrity, Authenticity, Accountability, Confidentiality |
| Log history | [01/18/2016]: Added to repository |
References
Garfinkel, S.L., 2005. Design principles and patterns for computer systems that are simultaneously secure and usable (PhD thesis). Massachusetts Institute of Technology.