Topic: authentication
Topic: communication protocols
Topic: digital signature
Topic: distributed system security
Topic: encryption
Topic: public key encryption
Topic: reliability of distributed systems
Topic: replicated data
Topic: security by capabilities
| |
Subtopic: authentication
Quote: passwords should also provide mutual authentication, authenticated key exchange, and user identity protection [»haleS8_1999]
| Subtopic: authentication server
Quote: a local security policy usually delegates authorization to trusted credential issuers
| Quote: split large-scale systems into security domains with their own SD-key server and key-access partition; tag all wrapped objects [»michJR9_2000]
| Subtopic: key continuity
Quote: use key continuity for public-key management; a known, good key confirms a remote party's identity; e.g., SSH [»gutmP2_2004]
| Subtopic: public key infrastructure
Quote: shouldn't unnecessarily divulge information, e.g., public keys should remain secret from non-users [»giffDK4_1982]
| Quote: a key server or certifying authority can "introduce" users to each other with signed, public-key certificates [»zimmPR_1995]
| Quote: for public key infrastructure choose locally meaningful identifiers, avoid revocation, use freshness guarantee, design for a purpose [»gutmP8_2002]
| Quote: need a trusted public key directory, otherwise cannot trust a digital signature [»gelbB12_2000]
| Quote: a public password is a written digest of the authentication server's public key; needed for password protocols [»haleS8_1999]
| Quote: never trust a public key that isn't signed by someone you trust, i.e., someone whose trusted public key is on your key ring [»zimmPR_1995]
| Subtopic: self-organized key management
Quote: use fully self-organized, pairwise key management for mobile ad hoc networks (MANET); authority-based approaches do not work well, e.g., problems with certificate renewal and revocation [»vandJ4_2007]
| Subtopic: escrow
Quote: a encryption key owner may cheat any escrow system by encrypting data with a private key; escrow check file guards against mistakes, not deception [»blazM6_1994]
| Quote: use smartcards for temporary escrow of file encryption keys; bilaterally auditable, past possession conveys no future privileges [»blazM6_1994]
| Quote: implemented temporary escrow of file encryption keys by lazy evaluation with a smartcard; may be equivalent to 3-DES [»blazM6_1994]
| Subtopic: forgery
Quote: public-key cryptosystems are vulnerable to forgery and man-in-the-middle attacks [»zimmPR_1995]
| Quote: prevent public key forgery with signed public key certificates from mutually trusted friends; allows centralized and decentralized approaches [»zimmPR_1995]
| Subtopic: Internet
Quote: authentication and key distribution must be extensible to large internetworks of many domains [»jansP4_1997]
| Subtopic: key distribution protocol
Quote: KryptoKnight is a family of light-weight, secure, two-way authentication and key distribution protocols based on one-way hashing [»birdR2_1995]
| Quote: KryptoKnight -- lightweight authentication and key distribution protocols based on pseudo-random one-way functions [»jansP4_1997]
| Quote: minimal, challenge-based protocol for key distribution between two parties [»jansP9_1995]
| Quote: three-party key distribution by braiding together two runs of two-party key distribution with a two-party authorization; distributed key can not be altered [»jansP9_1995]
| Quote: use one public key K to distribute many keys via chains of trust; K controls key-address pairs for verifying an edge relation [»jimT5_2000]
| Subtopic: session key, nonce
Quote: use a central, trusted authority to distribute session keys, a large random number used as a symmetric key [»rubiAD11_2000]
| Quote: Kerberos uses the Needham Schroeder protocol to establish a session key [»rubiAD11_2000]
| Quote: Kerberos issues a ticket to log into a server and a session key; the server authenticates the ticket and an authenticator built from the session key and the requestor's long-term key [»schnB_2000]
| Quote: the Leighton-Micali protocol for session keys separates confidentiality from authentication; elegant, efficient, and secure [»rubiAD11_2000]
| Quote: a freshly generated key is like a nonce: randomly generated by one party for one-time, key distribution [»jansP9_1995]
| Quote: broadcast encryption allows two devices to agree on a key via broadcast; use a key management block, e.g., indexed by device key; low cost, allows revocation [»lotsJ8_2002]
| Quote: use random keys and key rotation to counter brute force key attacks; suggested key size [»fuK8_2001]
| Subtopic: push vs. pull
Quote: use push model for key distribution in LANs (e.g., Kerberos); use pull model for wireless-networks with base stations (e.g., X9.17) [»jansP4_1997]
| Subtopic: limited lifetime
Quote: guarantee unconditional security by restricting the lifetime of each key; simple algorithms for synchronous cards [»gilbH9_1998]
| Subtopic: problems with key management
Quote: a central locksmith is wrong for large-scale file encryption key management; must be trusted, key database critical, single point of failure [»blazM6_1994]
| Quote: key management was tricky; used a secure processor in a credit control hierarchy; refilling the processor's credit counter required a higher level transaction [»andeRJ5_1996]
| Subtopic: problems with public key infrastructure
Quote: have not achieved a global, distributed public-key infrastructure; assumed by many security protocols [»gutmP2_2004]
| Quote: SSL/TLS clients contain more than 100 trusted certificates; many are unknown, unsecure, moribund, or resold; subverting one subverts all; 3/4 of web server certificates are invalid [»gutmP2_2004]
|
Related Topics
Topic: authentication (93 items)
Topic: communication protocols (62 items)
Topic: digital signature (25 items)
Topic: distributed system security (17 items)
Topic: encryption (45 items)
Topic: public key encryption (30 items)
Topic: reliability of distributed systems (35 items)
Topic: replicated data (51 items)
Topic: security by capabilities (65 items)
|