1 / 62

Security

Security. Paul Greenfield CSIRO. Optimistic Concurrency. Just before Security… Optimistic Concurrency Control No locks But check at commit or update if locks were really needed after all Check by … Seeing if data has changed between read and commit Looking at update sequence stamps.

onslow
Download Presentation

Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Security Paul GreenfieldCSIRO

  2. Optimistic Concurrency • Just before Security… • Optimistic Concurrency Control • No locks • But check at commit or update if locks were really needed after all • Check by … • Seeing if data has changed between read and commit • Looking at update sequence stamps

  3. Optimistic Concurrency • Return an exception if trying to change data that was changed after we read it Select next from keytable where type=1(remember value returned) …. Update keytable set next=next+1 where type=1(re-read old value of next and check that it has not changed between Select and Update. Return exception from Update if changed)

  4. Snapshot Concurrency • A form of optimistic concurrency • Used by Oracle • No read locks • Still have write locks • No waiting on read locks • Some update history kept inside data pages

  5. Snapshot Concurrency • Readers see the database as it was when they started their transaction • If record changed after reader started then older value retrieved from history • Return exception when getting update lock if record has changed since start of transaction

  6. Snapshot Concurrency • Uses transaction stamps on records • Has this record been changed by a later transaction? • Find older version if reading • Return exception if updating Tx_start (assign transaction stamp) Select next from keytable where type=1(if current t_stamp newer than start t_stamp then find suitable older record if possible) Update keytable set next=next+1 where type=1(try to get update lock. If current t_stamp > start t_stamp then return ‘cannot serialize’ exception)

  7. Snapshot Concurrency • Worth doing? • Better than doing page level locks • No conversion deadlocks • New ‘cannot serialize’ exception • May be no better or even worse than doing record level read locks • Return exception rather than waiting where lock conversion would be done

  8. Security • All about building and keeping trust… • Who is accessing my system? • What are they trying to do? • Is anyone eavesdropping? • Did you really send this message? • Can you deny that you sent it? • Has my system been compromised?

  9. Cryptography • Underlies most security techniques • One-way hashes • Encryption • Symmetric • Asymmetric • Algorithms are computationally difficult to break • Difficult but not impossible…

  10. One-way Hashes • Take data, such as file or message • Produce a small ‘hashed’ digest • Different digest for different data • Any change to data changes the hash • Cannot derive original data from hash • Examples: MD5, SHA-1 • Basis for digital signatures

  11. Encryption/Decryption • Encryption • turns ‘plain text’ to ‘cipher text’ • Decryption • turns ‘cipher text’ back into ‘plain text’ • A long history… • Substitution ciphers • A -> Z, B -> Y, … • Transposition ciphers • Swap 1st letter with 2nd, ….

  12. Encryption/Decryption • Modern algorithms use ‘keys’ • Algorithm often well-known • Need to know key to decrypt cipher text • Keys come from a very large space • 56 bits -> 72,057,594,037,927,936 keyschecking 1,000,000/sec -> 2,284 years • Symmetric and asymmetric • Is the same key used for encrypting and decrypting?

  13. Symmetric Algorithms • Same key encrypts and decrypts • Key is a shared secret between sender and receiver • How are keys distributed?

  14. Asymmetric Algorithms • A pair of related keys • Encrypt with one, decrypt with other • Cannot encrypt and decrypt with the same key • Normally one key is public and one is kept private • Encrypt with public, only owner of private key can decrypt • Encrypt with private, anyone with public key can decrypt

  15. Asymmetric Algorithms • Both directions? • A -> B encrypted with B’s public key • B -> A encrypted with A’s public key • Often called ‘public key’ encryption

  16. Asymmetric Algorithms • No shared secrets • No key distribution problem • Public key can be widely distributed • Computationally difficult to derive private key from public key • Slower (10 – 1000) times than symmetric algorithms • Too slow for general use

  17. Hybrid Algorithms • Combine symmetric and asymmetric • Avoid secure key exchange problem • Good performance • Create new, random session keys • Exchange session keys using asymmetric algorithms • Exchange messages using symmetric algorithms and session keys

  18. Hybrid Algorithms

  19. Digital Signatures • Undeniably associate the signer of a document with its content • Identifies who signed it • Signature applies to only one document • Document has not been altered since it was signed • Like a real signature only stronger • Being legally accepted • No technologies specified in law

  20. Digital Signatures • Normally combine one-way hash with public key encryption • Hash document • Encode hash with private key

  21. Digital Signatures • Verifying signature • Decode hash using known public key • Re-hash document & check hashes match

  22. Fundamental Services • Privacy • Data is protected against eavesdroppers • Provided by encryption • Integrity • Data has not been altered • Provided by digital signatures • Non-repudiation • Signer cannot deny signing • Provided by digital signatures

  23. Fundamental Services • Authentication • Who sent a message • Who received it • Who is trying to gain access • All concerned with identifying people and organisations • Is this really someone I trust?

  24. Authentication • Who sent or wrote this? • Provided by digital signatures • Not provided by Internet mail headers! • Who received it? • Encrypt with public key of intended recipient • No-one else can decrypt and read it

  25. Authentication • Who is trying to gain access? • Is this user who they really claim to be? • Many techniques of varying effectiveness • Passwords, biometrics, smart cards, … • Need to be proof against: • Eavesdropping • Replay attacks • Stolen passwords and tokens/cards • Guessed/cracked passwords

  26. Authentication • Techniques all based on some thing that is unique to a user • A secret like a password or PIN • A possession, such as smart card • Some physical characteristic • Combine techniques to overcome weaknesses • Protect smart card with a PIN

  27. Authentication Attacks • Eavesdropping • Just listen in to the logon sequence • Works for any identifying string • Password, fingerprint, … • Identifying data always has to be sent encrypted • Identifying data must always be kept encrypted everywhere • Clients, servers, …

  28. Authentication Attacks • Replay attacks • Just record and replay a logon • Works with encrypted identifying data • Password guessing • Guess passwords • Automated attacks using password generators and dictionaries • Defence is using non-trivial passwords • With OS mandating policy

  29. Authentication Attacks • Stolen passwords • Look at the bits of yellow paper… • Protect using physical tokens or biometrics • Stolen smart cards & tokens • Protected with another secret • PINs and passwords

  30. Secure Authentication • Challenge-response (CHAP) • Internet and Windows algorithm • Client knows the password • Server knows only a hashed password • Random challenge to defeat replay attacks

  31. CHAP Client Server Send logon request Send back random challenge Hash passwordHash hashed password and challenge to get responseSend response Retrieved hashed passwordHash hashed password and challenge to get responseCheck against client response

  32. Secure Authentication • Kerberos • Provides secure access to a network of computers from a single log-on • A shared secret (password) system • Internet RFC 1510 • Originally from MIT • Supported on UNIX, MVS, Win2000

  33. Kerberos • Four different players… • Clients • Authentication servers • Verify users during login • Secure session from client to TG server • Ticket-granting servers • Issue ‘proof of identity’ tickets • Identify clients to applications • Applications

  34. Kerberos • Eavesdropping? • Uses encryption on critical parts of messages • Only intended recipients can decode • Replay attacks? • Time stamps on critical messages • Tickets have limited lifetimes

  35. Secure Authentication • One-time passwords • Passwords generated as needed and only ever used once • Used for some highly secure systems • Lists of passwords • Generated by server • Cannot derive one password from another • Transferred to user via secure channel • Use next password every log-on • Paper list? Smart card?

  36. One-time Passwords • S/Key • Generate password only when needed • On client when logging in • On server when checking • Client side needs program/calculator to generate next password from user’s own secret key

  37. Biometrics • Identifying a person through some physical characteristic • Varying reliability, cost and acceptability • Fingerprints work well but poor public image • All measurements are approximate • ‘near enough’ matching allows for errors • Still subject to attacks • Need to combine with other techniques or physical security

  38. Biometrics

  39. Certificates • A digital document identifying a user or organisation • Issuing authority • Dates when certificate is valid • Details of subject • Subject’s public key • Signature of issuing authority • Often use X.509 standard

  40. Certificates • Trusted way to distribute public keys • Validate contents by checking signature • Need to know issuer’s public key • How do we know this? • Ask or just know it • Windows 2000 comes with 120+ certificates pre-loaded • Can the issuer be trusted? • Who issued their certificate? • What checking did they do?

  41. Certificates • Use? • Known, trusted way of distributing public key and other details of the intended recipient • Trust hierarchies • Chain of signing authorities • Leading up to a ‘root’ Certificate Authority (CA)

  42. Root CA CA CA End user End user CA CA End user End user End user End user End user CA Hierarchy

  43. Certificate Revocation • What happens when a certificate needs to be withdrawn? • Employee leaves a company • Credit card withdrawn • Certificate revocation lists • Signed by issuing CA • Pushed out via file transfer or mail… • Checked on-line • Compare with credit card lists

  44. Public Key Infrastructure • The infrastructure needed to use public key technology on a national scale. Normally based on X.509. • Root CA’s • Issuing CA’s • Policies and standards • Interoperable technologies

  45. PKI in Australia • Gatekeeper • Federal government body setting standards for CA’s • Accredited CA’s • Usage • Tax Office issuing ABN-DSC for signing electronic GST returns • Health issuing certificates to doctors for bulk-billing

  46. Network Security e-commerce Application layer Application layer specific protocols Data representation to Messaging Messaging applications S/MIME, security security PGP/MIME Transport layer SSL/TLS, SSH Transport layer Data delivery IPSec Network layer Data addressing, transmission Network layer Hardware link Link layer Link layer Network access protocols encryption Internet

  47. IPSec • Standard for secure IP networking • Packet authentication only • Packet authentication and encryption • Part of IPv6 but can be used with IPv4 • Basis for a more secure Internet • Access control, encryption, integrity, tunnelling, origin authentication, defence against replay attacks

  48. Virtual Private Networks • A secure private network running over the public Internet • Uses ‘tunnelling’ • Wrap IP packets inside another packet so that it can travel the ‘net • Packets are normally encrypted • Standards • PPTP, L2TP, IPSec

  49. VPNs

  50. Transport-level Security • Secure TCP connections • SSL and TLS (derived from SSL3) • Secure channel between two programs • Privacy, data integrity • Identity of end-users can be assured • Uses almost everything • Public keys, symmetric keys, hashing • Very widely used especially on Web

More Related