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 - Create Keys When Needed
Luigi Lo Iacono, Peter Nehren
January 18, 2016
Create Keys When Needed
| Name | Create Keys When Needed |
| Sources | (Garfinkel, 2005), (Ylönen, 1996) |
| Synonyms | None |
| Context | The use of encryption between unauthenticated endpoints protects the data from passive eavesdropping. These attacks are easier than active man-in-the-middle attacks, so it makes sense to defend against them by default. |
| Problem | How to protect data from passive eavesdropping? |
| Solution | Ensure that cryptographic protocols that can use keys will have access to keys, even if those keys were not signed by the private key of a well-known certificate authority. |
| Examples | Most SSH distributions are configured to automatically create host keys when the server starts if no keys are found.  Source: (Garfinkel, 2005) |
| Implementation | When a program that can use an X.509 certificate for authentication discovers that it does not have an X.509 certificate, a self-signed certificate should be made for default use. |
| Consequences | Systems that require cryptographic keys can be immediately used without the need to obtain certification from third-parties. This allows for both confidentiality and integrity protection without authentication control, which is better than no cryptographic protection at all. |
| Dependencies | None |
| Relationships | [Key Continuity Management] [Track Received Keys] |
| Principles | [Good Security Now] |
| Guidelines | None |
| Check lists | None |
| Use cases | None |
| Tags | Key Management |
| 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.
Ylönen, T., 1996. SSH: Secure login connections over the internet, in: Proceedings of the 6th Conference on USENIX Security Symposium, Focusing on Applications of Cryptography - Volume 6, SSYM’96. USENIX Association, Berkeley, CA, USA, pp. 4–4.