1 / 18

Encryption

Encryption. An Overview. Fundamental problems. Internet traffic goes through many networks and routers Many of those networks are broadcast media Sniffing allows for many to see transmissions Tamper/alter transmission Spoof identities. Security Issues. Eavesdropping Tampering

ward
Télécharger la présentation

Encryption

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. Encryption An Overview

  2. Fundamental problems • Internet traffic goes through many networks and routers • Many of those networks are broadcast media • Sniffing allows for many to • see transmissions • Tamper/alter transmission • Spoof identities

  3. Security Issues • Eavesdropping • Tampering • Impersonation • Spoofing • misrepresentation

  4. General Areas • Encryption/Decryption • Indentification/Authentication • Authorization • Tamper Detection • Nonrepudiation • Example using SSL • Example using SSH

  5. Private Key Encryption Decryption Algorithm Encryption Algorithm Encrypted Message Message Message PrivateKey PrivateKey Key distribution/Protection is Critical!

  6. Public Key Encryption Decryption Algorithm Encryption Algorithm Encrypted Message Message Message PublicKey PrivateKey Public Key distribution/Protection is NOT Critical! Only the Private Key will enable decryption

  7. Public Key Encryption - reverse Process is symmetric in the sense that private-encrypted can also ONLY be decoded with the public key Decryption Algorithm Encryption Algorithm Encrypted Message Message Message PrivateKey PublicKey Use you own private key to encrypt Let others have your public key.. No one can spoof you

  8. Encryption/Decryption Algorithm • Private or public key • Size of key • Harder to break/decipher • Key strength also related to algorthm • 128bit private stronger than 128bit public • Time Life of the key • Crackable in a month, change every day • Time to calculate • Impact on communication delays • Private-key faster than public key techniques

  9. Lots of Algorithms in use • DES • DSA • MD5 • RC2 and RC4 • RSA • SHA • SKIPJACK

  10. Identification/Authentication • Certificate from Certificate Authorities • Key is to trust the CA agency. • If two parties trust different CA agencies but the two trust each other, a hierarchical trust relationship can exist. • Problem scenario • Bill publishes his public key for others (Mary) • Bob publishes a public key posing as Bill • Only a trusted CA can verify that Bill’s public key is really from Bill • Bill includes a digitally signed certificate from a CA attesting to the public key

  11. Public Key Certificate(Bill <--> Mary) CA Agency Private Key Signing Process User Public key Identity (Bill) MARY MUST TRUST CA CA Agency Public Key Mary Decrypts Digital Signature Accept or reject

  12. Digital Signature Tamper Detection Hash Algorithm (MD5) Message (maybe big) Hash Value Encrypted Hash Value Encrypt Hash (RSA) Private key Send to receiver… checks by decrypting the hash with public key.. Small data to encrypt .. Detects tampering w/o encoding whole mesg.

  13. Authorization • Often overlooked • Not encryption but related • Once authenticated, is this person actually authorized, have the rights and permissions, to do what this user is asking.

  14. Nonrepudiation • When using an electronic signature • Can the person deny it actually came from them • Digital signatures are legal • For public/private key encryption, the only way that the signature could be invalid is if the private key was made public.

  15. SSL • Rides over the transport layer • Uses certificates for authentication • Server authentication • Optionally client authentication • BROWSER must tust CA • Sets up the communication using public-private keys to negotiate and establish symmetric private keys • Send rest of communication encrypted

  16. SSL handshake from docs.sun.com • The client sends the server the client's SSL version number, cipher settings, randomly generated data, and other information the server needs to communicate with the client using SSL. • The server sends the client the server's SSL version number, cipher settings, randomly generated data, and other information the client needs to communicate with the server over SSL. The server also sends its own certificate and, if the client is requesting a server resource that requires client authentication, requests the client's certificate. • The client uses some of the information sent by the server to authenticate the server (see Server Authentication for details). If the server cannot be authenticated, the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established. If the server can be successfully authenticated, the client goes on to Step 4. • Using all data generated in the handshake so far, the client (with the cooperation of the server, depending on the cipher being used) creates the premaster secret for the session, encrypts it with the server's public key (obtained from the server's certificate, sent in Step 2), and sends the encrypted premaster secret to the server. • If the server has requested client authentication (an optional step in the handshake), the client also signs another piece of data that is unique to this handshake and known by both the client and server. In this case the client sends both the signed data and the client's own certificate to the server along with the encrypted premaster secret. • If the server has requested client authentication, the server attempts to authenticate the client (see Client Authentication for details). If the client cannot be authenticated, the session is terminated. If the client can be successfully authenticated, the server uses its private key to decrypt the premaster secret, then performs a series of steps (which the client also performs, starting from the same premaster secret) to generate the master secret. • Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity--that is, to detect any changes in the data between the time it was sent and the time it is received over the SSL connection. • The client sends a message to the server informing it that future messages from the client will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the client portion of the handshake is finished. • The server sends a message to the client informing it that future messages from the server will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the server portion of the handshake is finished. • The SSL handshake is now complete, and the SSL session has begun. The client and the server use the session keys to encrypt and decrypt the data they send to each other and to validate its integrity.

  17. Typical Client check of SERVER CA(from docs.sun.com) Client CA check is similar

  18. SSH • Much simpler • Server contacts the client and asks if the client will accept the public key as authentic • Only server can decrypt • Client says yes. • All is done. • Client can authenticate different ways • Typically just with password. • Negotiate a symmetric private key for the session

More Related