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 - Track Received Keys
Luigi Lo Iacono, Peter Nehren
January 18, 2016
Track Received Keys
| Name | Track Received Keys |
| Sources | (Garfinkel, 2005) |
| Synonyms | None |
| Context | Tracking the use of keys is one of the techniques that security professionals use to determine how much credibility to put in a key, with the theory being that a key that has been seen a lot for a long time is more likely to be legitimate than a key that has been seen just once before. It makes sense to automate this process. |
| Problem | How can the credibility of keys be determined? |
| Solution | Make it possible for the user to know if this is the first time that a key has been received, if the key has been used just a few times, or if it is used frequently. |
| Examples |  Source: (Garfinkel, 2005) |
| Implementation | Maintain a key or certificate database that tracks the number of uses or frequency of use, in addition to tracking whether or not keys have been seen in the past. Track Received Keys could be implemented in a cryptographic toolkit or certificate store to provide the functionality in a uniform manner. |
| Consequences | Users can readily distinguish between keys that they have seen many times in the past and those that are new or relatively green. |
| Dependencies | None |
| Relationships | [Create Keys When Needed] [Key Continuity Management] |
| Principles | [Identifiability] |
| Guidelines | None |
| Check lists | None |
| Use cases | None |
| Tags | Track Received Keys, Key Management, Trust, Authenticity, Accountability |
| 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.