etm 555 1 security. etm 555 2 security fundamental requirements: 1.privacy 2.integrity...

45
ETM 555 1 Security

Post on 19-Dec-2015

216 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 1

Security

Page 2: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 2

SECURITY

• Fundamental Requirements:

1. Privacy

2. Integrity

3. Authentication

4. Non-repudiation

5. Availability

Page 3: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 3

SECURITY

• Privacy issue:

- How do you ensure that that the information you transmit over the Internet has not been captured or passed on to a third party without your knowledge.

• Integrity Issue

- How do you ensure the information you send or receive has not been compromised or altered

Page 4: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 4

SECURITY

• Authentication issue:

- How do sender and receiver of a message prove their identities to each other

• Non-Repudiation Issue:

- How do you legally prove that a message was sent or received

• Availability Issue:

- How do we ensure that the network and the computer system it connects will stay in operation continuously

Page 5: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 5

Cryptography

• Cryptography: transforms data using a key (a string of digits that acts as a password) to make the data incomprehensible to all but the sender and the intended receiver

•Plaintext: unencrypted data

•Ciphertext: encrypted data

•Cipher/Cryptosystem: technique/algorithm for encrypting messages

•Simple examples of cryptosystem:

-Substitution

-Transposition

Page 6: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 6

Secret key (Symmetric) Cryptography

• uses same (symmetric) keys to encrypt/decrypt a message

• fundamental problem: before two people can communicate, they must first find a way to exchange the symmetric key securely

• Point-to-point key exchange

• Centralized: Key distribution center generates a session key

• DES algorithms developed by NSA and |IBM in the 1950s

Page 7: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 7

Public Key (Asymmetric) Cryptography

• developed by Diffie & Hellman (Stanford Univ) 1976

• Two inversely related keys are used:

1. Public key : freely distributed

2. Private key: kept secret by its owner

• Either the public key or the private key can be used to encrypt or decrypt a message

• If the public key is used to encrypt a message, only the corresponding private key can decrypt it

• Vice versa: if the private key is used to encrypt a message, only the corresponding public key can decrypt it (this can be used to authenticate the sender of the message)

Page 8: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 8

Public Key (Asymmetric) Cryptography• The defining property of a secure public key is that it is computationally infeasible to deduce the private key from the public key

•Public key algorithms require large amounts of computer power

•Symmetric systems are faster

•RSA : most commonly used public key algorithm (developed by Rivest, Shamir, Adleman, MIT Professors, in 1977)

Page 9: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 9

Key Agreement Protocols

• Public key algorithms can be used to allow two parties to agree upon a key to be used as secret key to be used for symmetric key encryption over insecure medium

•Digital Envelope:

-message is encrypted using a symmetric key

-Symmetric key is encrypted using public key

-Attach encrypted symmetric key to encrypted message and send the entire package

-To decrypt: receiver first decrypts the symmetric key using the receiver’s private key. Then the symmetric key is used to decrypt actual message

Page 10: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 10

SECURITY-Hash Function

• Also known as “message digest”

• Mathematical function that gives message a hash value

• The chance that two different messages will have the same message digest is statistically insignificant

• Collision occurs when multiple messages have the same hash value

• It is computationally infeasible to compute a message from its hash value or to find two messages with the same hash value

• Example: MD5

Page 11: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 11

SECURITY- Digital signatures

• Solve problems of integrity and authentication

• Like a written signature, authenticates sender’s identity

• To create a digital signature

1. Run original plaintext message through hash (message digest)

2. Encrypt message digest using sender’s private key (creates a digital signature and authenticates the sender)

3. Encrypt original message with receiver’s public key

4. Send (encrypted message+digital signature+hash function) to the receiver

Page 12: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 12

SECURITY – Digital Signatures

• Receiver:

1. Receives the package

2. Uses sender’s public key to decipher the digital signature and reveal the message digest

3. Uses receiver’s own private key to decipher the original message

4. Applies the hash function to the original message

5. Compare the deciphered message digest to the result of hash function

Page 13: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 13

SECURITY – Digital Signatures

• Digital signatures do not provide the proof that a message has been sent

• A time-stamping agency (third party) can help to solve the non-repudiation problem by digitally signing the time-stamp

• US government recently passed digital-signature legislation that makes digital signatures as legally binding as hand-written signatures

Page 14: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 14

Public Key Infrastructure (PKI)

• How does a customer know that the web site it is accessing belongs to a trustworthy merchant and not to a third party site that is acting as merchant to steal credit-card information

• PKI integrates public-key cryptography with “digital certificates” and “certification authorities (CA)” to authenticate parties in a transaction

• Digital Certificate: is a digital document issued by a CA and includes:

-name of the subject (being certified)

-Subject’s public key

-Expiration date

- … plus other relevant information

• CA is a financial institution or other trusted third party such as VeriSign or Thawte

Page 15: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 15

CA • CA takes the responsibility for authentication, it checks the validity of

information before issuing a digital certificate

• Digital certificates are publicly available in CA certificate repositories

• CA signes the certificate by encrypting either the public key or a hash value of the public key using the CA’s own private key

• CA has to verify every individual’s public key. Thus users must trust the public key of a CA.

• A certificate authority is a chain of certificates starting with the root certification authority IPRA (Internet Policy Registration Authority)

• Root only signs certificates for policy creation authorities (organizations that set policies for obtaining digital certificates)

• Policy creation authorities sign digital certificates for Cas

• CA s sign digital certificates for individuals, organizations

Page 16: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 16

SECURE SOCKETS LAYER (SSL)

• SSL protocol developed by Netscape

• Built into web browsers and numerous other products

• When you use the Internet, the connection between you and any other point can be routed through dozens of independent systems (unauthorized people can steal confidential information, credit card numbers etc by eavesdropping)

• SSL protocol was developed to transfer information privately and securely across the Internet

• SSL is the de facto standard for encrypted and authenticated communications between clients and servers on the Internet

• Virtually all online purchases and monetary tansactions on the Internet are secured by SSL

• URL starts with https:

Page 17: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 17

SSL• SSL usage is not just limited to securing e-commerce transactions; other SSL

usage examples:

-financial institutions, insurance companies, B2B, private organizations

• SSL ensures that connection is private and secure by providing authentication and encryption

• Authentication confirms the server and optionally the client are who they say they are

• Encryption creates a secure ‘tunnel’ between the client and the server which prevents any unauthorized system from reading the data

• SSL-enabled clients: Netscape, MS Internet Explorer

• SSL-enabled servers: Apache or MS IIS

• Clients and Servers confirm each other’s identities using digital certificates which are issued by CA.

Page 18: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 18

SSL• SSL is comprised of two protocols:

1. Handshake Protocol: (key exchange)

2. Record Protocol (bulk data transfer)

Page 19: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 19

SSL- Handshake Protocol

1. Authenticates the server to the client (optionally the client to the server) using public-key encryption (asymmetric) techniques

2. Allows client and server to negotiate the cipher suite to be used

3. Allows the client and the server to generate symmetric session keys

4. Establishes the encrypted session

• Once key exchange is complete, client and server use symmetric session keys to encrypt all communication between them (SSL Record Protocol)

• Symmetric encryption algorithm such as DES or RC4 is used.

Page 20: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 20

SSL Negotiation Steps1. Initially request for SSL session comes from the browser to the web server

2. Web server sends the browser its digital certificate (contains info about the server and server’s public key)

3. Browser verifies that certificate is valid and that a CA listed in the client’s list of trusted CA’s issued it. Browser also checks expiration date and web server domain name

4. Once browser has determined that the server certificate is valid, browser generates a 48-byte master secret. This master secret is encrypted using server’s public key and is then sent to the Web server

5. Web server receives the encrypted master secret from the browser and decrypts it using the server’s private key

6. Both web server and the browser have the same secret key

7. Communicate securely by encrypting data using symmetric technique

Page 21: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 21

SSL Negotiation StepsSSL Negotiation Steps

Page 22: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 22

• SSL sits on top of TCP at the transport layer

• SSL operates independently and transparently of other protocols so it will work with any application layer and transport layer protocol

• This allows clients & servers to establish secure SSL connections w/o requiring knowledge of other party’s code

Page 23: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 23

Secure Electronic Transaction (SET)• developed by Visa and Mastercard

• Uses digital certificates to authenticate each party in an e-commerce transaction, including the customer, the merchant, and the merchant’s bank

• Public-key cryptography is used to secure information as it is passed over the web

• Merchants must have digital certificate and special SET software to process transactions

• Customers must have digital certificate and digital wallet software

• Digital wallet is similar to a real wallet ; it stores credit card information as well as digital certificate verifying cardholder’s identity

• Client’s credit card number is not stored on the merchant’s server

Page 24: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 24

SET

• When a customer is ready to place an order:

1. Merchant’s SET software sends the order information and the merchant’s digital certificate to the customer’s digital wallet

2. Customer selects credit card to be used for the transaction

3. Credit card and order information is encrypted by using the merchant’s bank public key and sent to the merchant along with the customer’s digital certificate

4. Merchant then forwards the information to the merchant’s bank to process the payment

5. Only merchant’s bank can decrypt the message since the message was encrypted using bank’s public key

Page 25: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 25

SET

6. The merchant’s bank then sends the amount of purchase and its own digital certificate to the customer’s bank to get approval to process the transaction

7. If the customer’s charge is approved, customer’s bank sends an authorization back to the merchant’s bank.

8. Merchant’s bank then sends a credit card authorization back to the merchant

9. Finally merchant sends a confirmation of order to the customer

Page 26: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 26

Microsoft Authenticode

• How do you know software you ordered online is safe and has not been altered ?

• Do you trust the source of the software ?

• Microsoft authenticode combined with VeriSign digital certificates authenticates the publisher of the software

• Authenticode is a security feature built into Microsoft Internet Explorer

Page 27: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 27

SECURITY ATTACKS

• Denial-of-service: attack occurs when a network’s resources are taken up by unauthorized individual, leaving the network unavailable for legitimate users

• Another type of attack: modifies routing tables of a network, thus disabling network ability or funneling all data to one address in the network

• Distributed denial service attacks ( attack does not come from one single source, but rather from multiple sources

Page 28: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 28

Denial of Service Attack• A "denial-of-service" attack is characterized by an explicit

attempt by attackers to prevent legitimate users of a service from using that service. Examples include

- attempts to "flood" a network, thereby preventing legitimate network traffic

- attempts to disrupt connections between two machines, thereby preventing access to a service

- attempts to prevent a particular individual from accessing a service

- attempts to disrupt service to a specific system or person

• Illegitimate use of resources may also result in denial of service. For example, an intruder may use your anonymous ftp area as a place to store illegal copies of commercial software, consuming disk space and generating network traffic

Page 29: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 29

Modes of Attack

• Consumption of scarce, limited, or non-renewable resources

- Network connectivity,

- Using Your Own Resources Against You

- Bandwidth Consumption

- Consumption of Other Resources

• Destruction or alteration of configuration information

• Physical destruction or alteration of network components

Page 30: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 30

Network Connectivity

Client Server

SYN-------------------->

<--------------------SYN-ACK

ACK-------------------->

-- Client and server can now send

service-specific data --

• half open connection (client does not send ACK)

Page 31: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 31

Using Your Own Resources Against You

• The intruder uses forged UDP packets to connect the echo service on one machine to another machine

• The result is that the two services consume all available network bandwidth between them

• Thus, the network connectivity for all machines on the same networks as either of the targeted machines may be affected.

Page 32: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 32

Bandwidth Consumption

• An intruder may also be able to consume all the available bandwidth on your network by generating a large number of packets directed to your network.

• Typically, these packets are ICMP ECHO packets, but in principle they may be anything.

• Further, the intruder need not be operating from a single machine; he may be able to coordinate or co-opt several machines on

different networks to achieve the same effect.

Page 33: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 33

Network Security

• Firewalls protect local area network from intruders outside the network (packet filters)

• Kerberos: (internal authentication) ; employs symmetric secret-key cryptography to authenticate users in a network and to maintain integrity and privacy of network communications

Page 34: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 34

Further Reading

http://www.cert.org/tech_tips/denial_of_service.html

Page 35: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 35

Databases

Page 36: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 36

NEO4J (Graphbase)• A graph is a collection nodes (things) and edges (relationships) that connect pairs of nodes.

• Attach properties (key-value pairs) on nodes and relationships

•Relationships connect two nodes and both nodes and relationships can hold an arbitrary amount of key-value pairs.

• A graph database can be thought of as a key-value store, with full support for relationships.

• http://neo4j.org/

Page 37: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 37

NEO4J

Page 38: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 38

NEO4J

Page 39: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 39

NEO4J

Page 40: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 40

NEO4J

Page 41: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 41

NEO4J

Page 42: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 42

NEO4JProperties

Page 43: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 43

NEO4J Features

• Dual license: open source and commercial•Well suited for many web use cases such as tagging, metadata annotations, social networks, wikis and other network-shaped or hierarchical data sets• Intuitive graph-oriented model for data representation. Instead of static and rigid tables, rows and columns, you work with a flexible graph network consisting of nodes, relationships and properties.• Neo4j offers performance improvements on the order of 1000x or more compared to relational DBs.• A disk-based, native storage manager completely optimized for storing graph structures for maximum performance and scalability• Massive scalability. Neo4j can handle graphs of several billion nodes/relationships/properties on a single machine and can be sharded to scale out across multiple machines•Fully transactional like a real database•Neo4j traverses depths of 1000 levels and beyond at millisecond speed. (many orders of magnitude faster than relational systems)

Page 44: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 44

Transactions

UPDATE account1 SET balance=balance-500; UPDATE account1 SET balance=balance+500;

1. Debit 100 TL to Groceries Expense Account2. Credit 100 to Checking Account

• A transaction is simply a number of individual queries that are grouped together. •Transactions provide an "all-or-nothing" proposition, stating that each work-unit performed in a database must either complete in its entirety or have no effect whatsoever.

Page 45: ETM 555 1 Security. ETM 555 2 SECURITY Fundamental Requirements: 1.Privacy 2.Integrity 3.Authentication 4.Non-repudiation 5.Availability

ETM 555 45

Transactions

• four conditions (ACID) to which transactions need to adhere

1. Atomicity: The queries that make up the transaction must either all be carried out, or none at all should be carried out

2. Consistency: Refers to the rules of the data. During the transaction, rules may be broken, but this state of affairs should never be visible from outside of the transaction.

3. Isolation : Simply put, data being used for one transaction cannot be used by another transaction until the first transaction is complete.

Connection 1: SELECT balance FROM account1; Connection 2: SELECT balance FROM account1;

Connection 1: UPDATE account1 SET balance = 900+100;

Connection 2: UPDATE account1 SET balance = 900-100;

4. Durability: Once a transaction has completed, its effects should remain, and not be reversible.