程序代写 RFC 1321) - PowCoder代写

Introduction
Network entities exchange information that may be critical to the operation of the internet and its services. The integrity of such information must be verifiable automatically without the need for complete human intervention. For some network entities, it is also important to verify if the sender’s details indicated in the message, is really the sender of that message. Moreover, some also need to communicate with confidentiality. How can all these tasks be achieved?

Examples of communicating network entities: web browser‐internet banking system, client‐server applications, router‐router, computer‐router, etc.
Security: 8‐ 2

 Router B receives a routing information from Router A. To authenticate the message:
1. Router B should verify that router A actually created the message (sender authentication)
2. Router B should verify that the message was not tampered on its way to Router B (message integrity)
Introduction
Example: Routers exchange routing information as part of their operations to enable them to compute for the complete map of the network.
 An attacker may inject bogus routing information to bring the network down. How can attacks like this be prevented?
Exchange of routing information among routers
Security: 8‐ 3

What is network security?
Symmetric key and Public key cryptography
Authentication
Message Integrity, Digital Signatures
Securing e‐mail
Security: 8‐ 4

Authentication
Process of proving one’s identity to someone else over a network
Authentication in the context of computer networking:
 A “live” party is being authenticated (often routers, client-server processes)
 cannot rely on biometric information
 must be done solely on the basis of messages and data exchanged
 must be performed before other protocols:
 Reliable data transfer protocol
 Routing information exchange protocol  E-mail protocol

Authentication
Let’s see a stepwise evolution of a design of an authentication protocol (ap)
Goal: Bob wants Alice to prove her identity to him Protocol ap1.0: Alice says ”I am Alice”
Failure scenario??
In a network, Bob cannot “see” Alice, so Trudy simply declares herself to be Alice

Authentication: using IP
Protocol ap2.0: Alice says ”I am Alice” and sends her IP address along to prove it. 
https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
Create an Operating system kernel that sends an IP datagram using Alice’s IP address
Not unless first-hop router of Trudy would prevent it
Failure scenario??

Authentication: Secret Password
Protocol ap3.0: Alice says ”I am Alice” and sends her secret password to prove it. 
Failure scenario?
Passwords are sent as cleartext for some applications (e.g. Telnet). However, packets can be sniffed, thus, not safe

Authentication: Encrypted Secret Password
Protocol ap3.1: Alice says ”I am Alice” and sends her encrypted secret password to prove it.
Assumption: Symmetric key cryptography is employed Shared Secret key
I am Alice encrypt(password)
Failure scenario?
Pitfall: same password is used over and over again.
*Password is not learned by Trudy
Playback attack:
record encrypted password, playback encrypted password version to Bob to pretend that she is to solve it?
Failure Scenario:
Countermeasures:
Playback Attack
Bob cannot distinguish between the original authentication and its playback version
Use a different password each time
• use a sequence of passwords or password generator (could be a number)
• apply encryption algorithm to each password
Bob knows: Alice is indeed sending the datagram, because she knows the secret
encryption key, and she is sending it “live” because she is using the number recently
generated by Bob.

Authentication: Sequence of Encrypted Secret Passwords
Protocol ap4.0: Nonce + Symmetric key Cryptography (Shared Secret Key)
Goal: avoid playback attack
Nonce: number (R) used only once-in-a-lifetime
Protocol ap4.0: to prove Alice is live, Bob sends Alice nonce, R. Alice
must return R, encrypted with shared secret key Figure 7.11 goes here
Failures, drawbacks?
We have a solution! Bob knows: Alice is indeed sending the datagram, because she knows the secret encryption key, and she is
sending it “live”

Protocol ap5.0: Nonce + Public key cryptography
*Note: eA(dA(R)) = R
Authentication: ap5.0
Previously, ap4.0 requires shared symmetric key – problem:howdoBob,Aliceagreeonkey
– canweauthenticateusingpublickeytechniques?
Figure 7.12 goes here

Protocol ap5.0: Nonce + Public key cryptography
Authentication: ap5.0
Previously, ap4.0 requires shared symmetric key – problem:howdoBob,Aliceagreeonkey
– canweauthenticateusingpublickeytechniques?
Problem: Trudy may be able to impersonate Alice, and generate her own messages.
Figure 7.12 goes here
*Note: eT(dT(R)) = R
Eventually, Alice & Bob may find together that someone else was interacting with Bob.
To solve this problem, use ‘certified’ public keys (more on this later…)
eT(dT(R))=R

Alice is happy to receive encrypted message using her own public key
Figure 7.14 goes here
Bob is happy to send encrypted data
To solve this problem, use ‘certified’ public keys (more on this later…)
This can also be solved using symmetric key cryptography – Bob & Alice know a secret key.
Alice & Bob may never know that Trudy was there all along.
ap5.0: security hole
Man-in-the-middle (MITM) attack: Trudy poses as Alice (to Bob)
and as Bob (to Alice), and quietly eavesdrop
In control of the router used by Alice

Key Distribution, Trusted Intermediaries
1. Problem:
2. Problem:
 How do Alice and Bob establish shared secret key over network?
 When Alice obtains Bob’s public key (from web site, e-mail), how does she know it is Bob’s public key, not Trudy’s?

Key Distribution, Trusted Intermediaries
1. Problem:
2. Problem:
How do Alice and Bob establish a shared secret key over a network?
 When Alice obtains Bob’s public key (from web site, e-mail), how does she know it is Bob’s public key, not Trudy’s?
Solution#1:
 Using public key cryptography Solution#2:
 Using a trusted key distribution centre (KDC) acting as intermediary between entities

Key Distribution, Trusted Intermediaries
1. Problem:
2. Problem:
 How do Alice and Bob establish a shared secret key over a network?
 When Alice obtains Bob’s public key (from web site, e-mail), how does she know it is Bob’s public key, not Trudy’s?
Solution#1:
 Using public key cryptography Solution#2:
 Using a trusted key distribution centre (KDC) acting as intermediary between entities
 trusted certification authority (CA)

Key Distribution using Public key cryptography Problem 1: How can Alice & Bob get a shared symmetric key in a secure way,
using public key cryptography?
 Alice and Bob want to communicate using symmetric key cryptography but do not have a shared symmetric key. This key is referred to as a session key, denoted by Ks.
 Public key cryptography can be used to distribute the session key from Alice to Bob.
 Sequence of Steps:
1. Alice chooses a session key, Ks
2. Aliceencryptsthesessionkey,KsusingBob’spublickey,eB (RSAalgorithm) then sends it to Bob.
3. Bob receives the encrypted session key, and decrypts it using his private key dB to obtain the session key. Bob now knows the session key that Alice will use for her encrypted data transfer.
Ks = dB (eB (Ks) ) 20

Key Distribution Center (KDC)
Problem 2: How can Alice & Bob get a shared symmetric key in a secure way,
without public key cryptography?
Alice and Bob needs a shared symmetric key.
KDC is a server that shares a unique secret symmetric key with each registered user.
Alice, Bob are registered users of KDC, they know their own symmetric keys, KA-KDC , KB-KDC , for communicating with KDC.

Key Distribution Center (KDC)
Problem 2: How can Alice & Bob get a shared symmetric key in a secure way, without public key cryptography?
Shared symmetric key = R1
(A, R1, etime)), KR1(nonce) KR1(nonce + 1)
3. Alicesends B-KDC(A,R1, etime), including an encrypted nonce
It’s Alice, I want to talk to Bob securely
Includes an expiration time
KDC uses the appropriate private user secret key to communicate with them.
Includes an R1-encrypted time-stamp (nonce) – Bob needs to use this in his reply to show that he is “live”
(A, R1, etime))
2. AlicereceivesasessionkeyR1,and KB-KDC(A,R1, etime)
1. AlicecommunicateswithKDC,requests for a session key to communicate with Bob.
4. BobextractsR1,etimeandthenonce
5. Alice, Bob now share the symmetric key R1. Bob increments the nonce and sends it to Alice, to prove that he is live.

Public key Certification Authorities (CA)
 Certification authority (CA) binds public key to particular entity.
-validates identities – issues certificates
 Entity (person, router, website, etc.) can register its public key with CA.
 Entity provides proof of identity to CA.
 CA creates certificate binding entity to public key. (also includes globally unique identifying info., such as human name or IP address)
certificate for Bob’s public key, signed by CA
 Certificate is digitally signed by CA.

Public key Certification Authorities (CA)
When Alice wants Bob’s public key:
 gets Bob’s certificate (from Bob or elsewhere).
 Apply CA’s public key to Bob’s certificate, get Bob’s public key
certificate for Bob’s public key, signed by CA

Certificate Sample
International Telecommunication Union (ITU) & IETF: set standards for CAs
For more info: https://sites.google.com/site/ddmwsst/digital-certificates

Which CA do we trust?
Sept. 13, 2018
At the end of July, the Chrome team and the PKI community converged upon a plan to reduce, and ultimately remove, trust in Symantec’s infrastructure in order to uphold users’ security and privacy when browsing the web
A public key infrastructure (PKI) is a set of rules, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates and manage public-key encryption
Chrome version
Default behaviour (block)
Chrome 66 to Chrome 69
Distrust Symantec-issued certificates issued after 2017/12/01 and before 2016/06/01, but allow all certificates issued between these dates.
Chrome 70 to Chrome 73
Distrust all Symantec-issued certificates.
Which CA do we trust? Let’s have a look at some relevant news!
https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html
https://support.google.com/chrome/a/answer/7662561?hl=en

What is network security?
Symmetric key and Public key cryptography
Authentication
Message Integrity, Digital Signatures
Securing e‐mail
Security: 8‐ 28

Digital signatures
cryptographic technique analogous to hand‐written signatures:
sender (Bob) digitally signs document: he is document owner/creator. verifiable, nonforgeable: recipient (Alice) can prove to someone that Bob,
and no one else (including Alice), must have signed document
simple digital signature for message m: –
• Bob signs m by encrypting with his private key KB, creating “signed” message, KB‐(m)
GENERAL STRATEGY (HIGHLY SIMPLIFIED)
m,KB-(m) Dear Alice
Bob’smessage,m Dear Alice
KB- Bob’sprivate key
Oh, how I have missed you. I think of you all the time! …(blah blah blah)
Public key encryption algorithm
Oh, how I have missed you. I think of you all the time! …(blah blah blah)

Digital signatures
 suppose Alice receives msg m, with signature: m, K -(m) B
 Alice verifies m signed by Bob by applying Bob’s public key K +to K -(m) then +- BB
checks KB(KB(m) ) = m.
 If KB(KB(m) ) = m, whoever signed m must have used Bob’s private key
Alice thus verifies that:
 Bob signed m
 no one else signed m
 Bob signed m and not m’
non‐repudiation:
Alice can take m, and signature KB(m) to court and prove that Bob signed m
Security: 8‐ 30

Message digest / Fingerprint
computationally expensive to public‐key‐encrypt long messages goal: fixed‐length, easy‐ to‐compute digital “fingerprint”
apply hash function H to m, get fixed size message digest, H(m)
Cryptographic hash function properties:
large message m
H: Hash Function
Message digest or Fingerprint
 many‐to‐1 (so collisions can happen)
 produces fixed‐size msg digest (fingerprint)
 given message digest x, computationally infeasible to find m such that x = H(m)
Security: 8‐ 31

Internet checksum: poor crypto hash function
Internet checksum has some properties of hash function:  produces fixed length digest (16‐bit sum) of message
 is many‐to‐one
but given message with given hash value, it is easy to find another message with same hash value:
I O U 100.99 B O B
I O U 900.19 B O B
We need a more powerful hash function than a checksum
ASCII format
ASCII format
I O U 1 0 0 . 9 9 B O B
49 4F 55 31 30 30 2E 39 39 42 D2 42
I O U 9 0 0 . 1 9 B O B
49 4F 55 39 30 30 2E 31 39 42 D2 42
B2 C1 D2 AC
different messages
B2 C1 D2 AC
but identical checksums!
Security: 8‐ 32

 SHA‐1 is also widely used and is also cryptographically broken
Cryptographic hash functions
 MD5 hash function is widely used, although cryptographically broken (RFC 1321)
• computes 128‐bit message digest in 4‐step process.
• arbitrary 128‐bit string x, appears difficult to construct msg m whose MD5
hash is equal to x
• Algorithm details, including Source code:
https://www.ietf.org/rfc/rfc1321.txt
• In 2008, the CMU Software Engineering Institute concluded that MD5 was essentially “cryptographically broken and unsuitable for further use
 SHA‐2 and SHA‐3 are the recommended ones • US standard [NIST, FIPS PUB 180‐1]
• 224, 256, 384 or 512‐bit message digest
Security: 8‐ 33

(also known as message authentication)

Message Authentication Code
Using Cryptographic hash function H() only
1. Alice creates message m and calculates the hash H(m) (for example with SHA-
2. Alice then appends H(m) to the message m, creating an extended message (m, H(m)), and sends the extended message to Bob.
3. Bob receives an extended message (m, h) and calculates H(m). If H(m) = h, Bob concludes that everything is fine.
Flaw: Trudy can create a bogus message m ́ in which she says she is Alice, calculate H(m ́), and send Bob (m ́, H(m ́)).
When Bob receives the message, everything checks out in step 3, so Bob doesn’t suspect anything wrong.

Message Authentication Code (MAC)
Using Cryptographic hash function + shared secret (s), also called authentication key
1. Alice creates message m, concatenates s with m to create m + s, and calculates the hash H(m + s) (for example with SHA-2).
H(m + s) is called the message authentication code (MAC).
2. Alice then appends the MAC to the message m, creating an extended message (m, h); where h = H(m + s), and sends the extended message to Bob.
3. Bob receives an extended message (m, h) and knowing s, calculates the MAC H(m + s).
If (H(m + s) == h), Bob concludes that everything is fine.
Note: Using a cryptographic function and a shared secret (authentication key), message integrity can be performed, but without confidentiality.
For routers exchanging routing information, the use of MAC for message authentication suffices as
confidentiality is not required. Avoiding the complex encryption steps is preferred as communication
speed is important for these routers.

Digital signature = signed message digest
Using Cryptographic hash function + public key cryptography Bob sends digitally signed message:
large message m
H: Hash Function
Message digest or Fingerprint
message digest
Bob’s private K-
digital signature (encrypt)
K- (H(m)) B
Digital signature
m , (KB‐ (H(m) )

Digital signature = signed message digest
message digest
Using Cryptographic hash function + public key cryptography
Bob sends digitally signed message:
Alice verifies signature, integrity of digitally signed message:
large message m
H: Hash Function
Message digest or Fingerprint
Bob’s private K-
digital signature (encrypt)
Bob used to create the message digest
Alice knows Bob’s public key Alice knows the Hash function
K- (H(m)) B
Digital signature
m , (KB‐ (H(m) )

Digital signature = signed message digest
large message m
H: Hash Function
Message digest or Fingerprint
Using Cryptographic hash function + public key cryptography
Bob sends digitally signed message:
Alice verifies signature, integrity of digitally signed message:
Bob’s private
digital signature (encrypt)
large message m
Bob’s public
digital signature (decrypt)
+- KB(H(m))
m , (KB‐ (H(m) )
encrypted message digest
H: Hash function
K + (K ‐ (H(m))) B B
message digest
Digital signature
K- (H(m)) B

(Recall) Background information: Computer System Organisation
I/O Devices, Device Controller, Device Driver
Local buffer storage
Set of special‐purpose registers
Device controller
e.g. disk controller, USB controller, graphics adapter, etc.
Device controller is in charge of a specific type of device (e.g disk, graphics device)
• Maintains some local buffer storage and a set of special-purpose registers.
• Moves data between peripheral device and its local buffer storage.
Device driver – software in charge of a specific device controller (typically supplied by device controller manufacturers
• Sends commands to the device controller by loading the appropriate registers in the device controller
• provides the OS with a uniform interface to the device.
Memory controller

Recall: Computer System Organisation I/O Devices, Device Controller, Device Driver
from other drivers and the OS.
Local buffer storage
Set of special‐purpose registers
Device controller
e.g. disk controller, USB controller, graphics adapter, etc.
Device drivers typically run in kernel mode.
All code that runs in kernel mode shares a single virtual address space. A kernel-mode driver is not isolated
If a kernel-mode driver accidentally overwrites a virtual address that belongs to the OS or other driver, the system would be compromised. It can also cause the entire OS to crash.
So, how can an OS trust that a device driver is safe to install?
Memory controller

Recall: Computer System Organisation Plug and Play (PnP) Device, Device Driver
Local buffer storage
Set of special‐purpose registers
Device controller
e.g. disk controller, USB controller, graphics adapter, etc.
When a PnP joystick is attached to a USB hub, this device is automatically detected by the USB host controller, informing a PnP manager to adapt to hardware changes with minimal intervention by the user
The PnP manager is a part of t

程序代写 CS代考加微信: powcoder QQ: 1823890830 Email: powcoder@163.com

Related Posts