16/3/2011 | | 16/3/2011 | | 16/3/2011 | | Most simple credential Usually password together with username Usually password case-sensitive, while username not; it depends To increase security Brute-force attacks: use longer password, both lower/upper case chars, also numbers and specials chars … Salt – example: password ADMINISTRATOR: easily recognizable, if hash value known – but not if salt was added! Salt: different systems different salts use of same password not recognizable OTP: with list - example: TANS with online banking To indirect influence resistance: restrict number of login attempts, whereupon system refuses further attemps
16/3/2011 | | 16/3/2011 | | 16/3/2011 | | X.509 introduces hierarchical PKI First introduce CA and Root CA CA: issues certs for other CA or for a subject (i.e. user or firm) Root CA: is trusted in the first place, cert build-in in popular browsers Verification: start at bottom (pic), verification recursive loop until Root CA If private key stolen/public, need to avoid missuse CRL List adress embedded into every certificate Check, if cert is on the regarding CRL
16/3/2011 | | 16/3/2011 | | 16/3/2011 | | Subject data Subject name (X.500) Unique serial number (unique per CA) Issuer Issuer name (X.500) Validity period (when to let issue a new cert) Fingerprint NOT VISIBLE: Version NOT VISIBLE: Subject‘s public key (needed for) NOT VISIBLE: Signature by issuer NOT VISIBLE: Extensions (since v3)
16/3/2011 | | 16/3/2011 | | 16/3/2011 | | Unique object identifier (for recognition) Data Value represented as string Criticality flag; behaviour if an extension is not supported List of used extensions of a subject certificate Extension „Certificate Key Usage“ – not critical; certificate should only be used for signing and key encipherment users with application, which does not support extension, would not accept cert, if critical
16/3/2011 | | 16/3/2011 | | 16/3/2011 | | computation/verification of checksums/signatures, hashing, encryption/decryption, verification of CVCs no need to rely on computer security (viruses, trojan horses) Less space, because no XML tags, but short tags (2 or 4 digits long) Header values: tags + lengths
16/3/2011 | | 16/3/2011 | | 16/3/2011 | | Every day situation – use of several services (email, online banking, blogging) User has to remember only one password How is auth info exchanged? Cookies: not possible across different domains Proprietary solution: possibly incompatible Short abstract – more details later by other seminar group
16/3/2011 | | 16/3/2011 | | 16/3/2011 | | More abstract exchange User uses service of an IdP, then information communicated to RP Protocols – for the regarding features of SAML i.e. Assertion Query and Request Protocol; Authentication Request Protocol Bindings Embed SAML messages into HTML POST requests, HTML forms, SOAP messages Profiles i.e. Web Browser SSO Profile ???
16/3/2011 | | 16/3/2011 | | 16/3/2011 | | Authentication: subject was authenticated by a particular means at a particular time Attribute: exchange of attributes regarding a subject (requests with specified criteria possible) Authorization decision: access to a specific ressource allowed for a subject? signatures and encryption possible with common used algorithms Subject confirmation data: confirm relationship of subject to assertion issuer Conditions: i.e. validity period, allow only one-time use Extensions: At many points (so no further explanations)
16/3/2011 | | 16/3/2011 | | 16/3/2011 | | All requests performed via HTTP Endpoint discovery: special path at domain of identifier Authentication, if no previous authentication to the OP
16/3/2011 | | 16/3/2011 | | 16/3/2011 | | No other services beyond that (but of course by extensions) To increase security … signatures possible Encryption not by OpenID itself, but by using SSL/TLS (OpenID messages unencrypted) Extension possible – but only key-value pairs AX: fetch/store attributes (like in SAML); representable as string PAPE: provider may request special policies, i.e. Phishing-resistant authentication to OP; time value, after which explicit reauthentication is required SREG: transfer by RP selected personal details (name, adress, date of birth, email adress)
16/3/2011 | | 16/3/2011 | | 16/3/2011 | |
16/3/2011 | | 16/3/2011 | | 16/3/2011 | |
16/3/2011 | | 16/3/2011 | |
16/3/2011 | | 16/3/2011 | | 16/3/2011 | | People almost certainly carry a Plastic Card around in their wallet. Perhaps they travel with a Railway Card, make calls with a Telephone Card, pay with a Credit Card, or obtain cash from an automatic teller machine using Eurocheque Card. All these Plastic Cards may be the same size, but sometimes have completely different functions [29]. We describe now different types of Plastic Card, and how they can be used as an HSM. 16/3/2011 | |
16/3/2011 | | 16/3/2011 | | 16/3/2011 | | Chip Cards The Chip Card (Figure 3) is more powerful than a simple Magnetic Stripe Card. These can be usually recognised by a gold-coloured metal contact surface about the size of a fingermail on the front (there are also non-contact Chip Cards, but these are not of interest here). Telephone Cards are the most well-known example of this species of Plastic Card. Behind the contact surface on a Chip Card there is a hardware chip, which is markedly more powerful than a magnetic stripe [29]. There are two kinds of Chip Card: Memory Card and Smart Card (externally these are the same) [29]. On a Memory Card, the chip is only used to store data and is not able to compute or control access to the stored data. A Smart Card, on the other hand, is a miniature computer: it has a processor, a genuine read-only memory (ROM), a working memory (RAM) and an electronically erasable programmable memory (EEPROM). These components are coordinated by a special Smart Card operating system. Input and output is possible via the contact surface on the front. Smart Cards nowdays typically have 16 Kbyte ROM, 2Kbyte EEPROM and several hundred bytes of RAM available [29]. 16/3/2011 | |
16/3/2011 | | 16/3/2011 | | 16/3/2011 | |
16/3/2011 | | 16/3/2011 | | 16/3/2011 | | Smart Cards have the drawback that they are useless without a reading device. As yet, however, only a few PCs and other machines have been equipped with them, which is why many users are looking for an alternative [29]. For authentication purposes there is an alternative in the form of the so-called smart token. A smart token is a small object with an inbuilt computer chip and a display. Most smart tokens look like a small pocket calculator, although some are in the form of wrist watches or key fobs. Many smart tokens have a keyboard, making them more likely to be mistaken for a pocket calculator. With a smart token, for example, the user Alice can authenticate herself through a challenge-response [8] protocol, without owning a Smart Card reader and without the software with cryptographic functions. Smart tokens are thus a secure alternative to passwords. To explain how a smart token works, we assume that Alice wants to access her online account at Cryptobank and uses a smart token to achieve this. Typically this works as follows 16/3/2011 | |
![Introduction ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],16/3/2011 | TUD | Department 20 | CDC | Electronic Credentials | S. Pöschel, A. Neziri & J. Budurushi](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)