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 - Key Continuity Management
Luigi Lo Iacono, Peter Nehren
January 18, 2016
Key Continuity Management
| Name | Key Continuity Management |
| Sources | (Garfinkel, 2005) |
| Synonyms | None |
| Context | Many SSL and S/MIME certificates in use today are not signed by well-known certificate authorities (CA). As a result, SSL clients such as Internet Explorer and S/MIME clients such as Outlook Express display errors. |
| Problem | How to avoid error messages shown by many SSL clients? |
| Solution | Use digital certificates that are self-signed or signed by unknown CAs for some purpose that furthers secure usability, rather than ignoring them entirely. This, in turns, makes possible the use of automatically created self-signed certificates created by individuals or organizations that are unable or unwilling to obtain certificates from well-known certification authorities. |
| Examples | Tracking of server keys in SSH clients.  Source: (Garfinkel, 2005) |
| Implementation | When certificates are received in the course of authentication and the certificates are not signed by a recognized CA, the system verifies the signature, then consults a local database of identities. If the identity is not present, the identity and the certificate are added. If the identity is present and the certificate on file for that identity is different, a warning is issued. When an identity is received that is not digitally certified and the identity is on file with a matching certificate, a warning is issued. |
| Consequences | Allows certificates that are self-signed or signed by unknown certificate authority to be used in a way that proves continuity of identity. |
| Dependencies | None |
| Relationships | [Track Received Keys] [Create Keys When Needed] |
| Principles | [Good Security Now] |
| Guidelines | None |
| Check lists | None |
| Use cases | None |
| Tags | Key Continuity Management, Track Received Keys, Key Management, Create Keys When Needed, Authenticity |
| 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.