868 lines
No EOL
78 KiB
HTML
868 lines
No EOL
78 KiB
HTML
|
||
<!DOCTYPE html>
|
||
|
||
|
||
|
||
|
||
<html lang="en">
|
||
<head>
|
||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
||
<title>5.4. Network Security Fundamentals — Computer Systems Fundamentals</title>
|
||
|
||
<link rel="stylesheet" href="_static/css/bootstrap.min.css" integrity="sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T" crossorigin="anonymous" />
|
||
<link rel="stylesheet" href="_static/css/pygments.css" type="text/css" />
|
||
<link rel="stylesheet" href="_static/css/normalize.css" type="text/css" />
|
||
<link rel="stylesheet" href="../../../JSAV/css/JSAV.css" type="text/css" />
|
||
<link rel="stylesheet" href="../../../lib/odsaMOD-min.css" type="text/css" />
|
||
<link rel="stylesheet" href="_static/css/jquery-1.11.4-smoothness-ui.css" type="text/css" />
|
||
<link rel="stylesheet" href="../../../lib/odsaStyle-min.css" type="text/css" />
|
||
<link rel="stylesheet" href="_static/css/csf.css" type="text/css" />
|
||
|
||
<style>
|
||
.underline { text-decoration: underline; }
|
||
</style>
|
||
|
||
<script type="text/javascript">
|
||
var DOCUMENTATION_OPTIONS = {
|
||
URL_ROOT: './',
|
||
VERSION: '0.4.1',
|
||
COLLAPSE_INDEX: false,
|
||
FILE_SUFFIX: '.html',
|
||
HAS_SOURCE: true
|
||
};
|
||
</script>
|
||
|
||
<script type="text/x-mathjax-config">
|
||
MathJax.Hub.Config({
|
||
tex2jax: {
|
||
inlineMath: [['$','$'], ['\\(','\\)']],
|
||
displayMath: [ ['$$','$$'], ["\\[","\\]"] ],
|
||
processEscapes: true
|
||
},
|
||
"HTML-CSS": {
|
||
scale: "80"
|
||
}
|
||
});
|
||
</script>
|
||
<link rel="shortcut icon" href="_static/favicon.ico"/>
|
||
<link rel="index" title="Index" href="genindex.html" />
|
||
<link rel="search" title="Search" href="search.html" />
|
||
<link rel="index" title="Computer Systems Fundamentals" href="index.html" />
|
||
<link rel="next" title="5. Internet Layer: IP" href="NetLayer.html" />
|
||
<link rel="prev" title="3. Transport Layer" href="TransLayer.html" />
|
||
|
||
</head><body>
|
||
|
||
<nav class="navbar navbar-expand-md navbar-dark navbar-custom fixed-top">
|
||
|
||
<a class="navbar-brand py-0" href="index.html"><img src="_static/CSF-Logo-Square-Text.png" alt="OpenCSF Logo" height="40em" class="py-1 px-2 mb-0 align-center rounded-lg bg-white" /></a>
|
||
<!-- Show a navbar toggler on mobile -->
|
||
<button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#defaultNavbars" aria-controls="defaultNavbars" aria-expanded="false" aria-label="Toggle navigation">
|
||
<span class="navbar-toggler-icon"></span>
|
||
</button>
|
||
<div class="collapse navbar-collapse" id="defaultNavbars">
|
||
<ul class="navbar-nav mr-auto">
|
||
<li class="nav-item dropdown">
|
||
<a class="nav-link dropdown-toggle jmu-gold rounded" href="NetSec.html#" id="navbarDropdownChapters" role="button" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false">Contents</a>
|
||
<div class="dropdown-menu scrollable-menu" role="menu" aria-labelledby="navbarDropdownChapters">
|
||
<a class="dropdown-item" tabindex="-1" href="NetSec.html#"><b>Chapter 1</b></a>
|
||
<a class="dropdown-item" href="IntroConcSysOverview.html"> 1.1. Introduction to Concurrent Systems</a>
|
||
<a class="dropdown-item" href="SysAndModels.html"> 1.2. Systems and Models</a>
|
||
<a class="dropdown-item" href="Themes.html"> 1.3. Themes and Guiding Principles</a>
|
||
<a class="dropdown-item" href="Architectures.html"> 1.4. System Architectures</a>
|
||
<a class="dropdown-item" href="StateModels.html"> 1.5. State Models in UML</a>
|
||
<a class="dropdown-item" href="SequenceModels.html"> 1.6. Sequence Models in UML</a>
|
||
<a class="dropdown-item" href="StateModelImplementation.html"> 1.7. Extended Example: State Model Implementation</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 2</b></a>
|
||
<a class="dropdown-item" href="ProcessesOverview.html"> 2.1. Processes and OS Basics</a>
|
||
<a class="dropdown-item" href="Multiprogramming.html"> 2.2. Processes and Multiprogramming</a>
|
||
<a class="dropdown-item" href="KernelMechanics.html"> 2.3. Kernel Mechanics</a>
|
||
<a class="dropdown-item" href="Syscall.html"> 2.4. System Call Interface</a>
|
||
<a class="dropdown-item" href="ProcessCycle.html"> 2.5. Process Life Cycle</a>
|
||
<a class="dropdown-item" href="UnixFile.html"> 2.6. The UNIX File Abstraction</a>
|
||
<a class="dropdown-item" href="EventsSignals.html"> 2.7. Events and Signals</a>
|
||
<a class="dropdown-item" href="Extended2Processes.html"> 2.8. Extended Example: Listing Files with Processes</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 3</b></a>
|
||
<a class="dropdown-item" href="IPCOverview.html"> 3.1. Concurrency with IPC</a>
|
||
<a class="dropdown-item" href="IPCModels.html"> 3.2. IPC Models</a>
|
||
<a class="dropdown-item" href="Pipes.html"> 3.3. Pipes and FIFOs</a>
|
||
<a class="dropdown-item" href="MMap.html"> 3.4. Shared Memory With Memory-mapped Files</a>
|
||
<a class="dropdown-item" href="POSIXvSysV.html"> 3.5. POSIX vs. System V IPC</a>
|
||
<a class="dropdown-item" href="MQueues.html"> 3.6. Message Passing With Message Queues</a>
|
||
<a class="dropdown-item" href="ShMem.html"> 3.7. Shared Memory</a>
|
||
<a class="dropdown-item" href="IPCSems.html"> 3.8. Semaphores</a>
|
||
<a class="dropdown-item" href="Extended3Bash.html"> 3.9. Extended Example: Bash-lite: A Simple Command-line Shell</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 4</b></a>
|
||
<a class="dropdown-item" href="SocketsOverview.html"> 4.1. Networked Concurrency</a>
|
||
<a class="dropdown-item" href="FiveLayer.html"> 4.2. The TCP/IP Internet Model</a>
|
||
<a class="dropdown-item" href="NetApps.html"> 4.3. Network Applications and Protocols</a>
|
||
<a class="dropdown-item" href="Sockets.html"> 4.4. The Socket Interface</a>
|
||
<a class="dropdown-item" href="TCPSockets.html"> 4.5. TCP Socket Programming: HTTP</a>
|
||
<a class="dropdown-item" href="UDPSockets.html"> 4.6. UDP Socket Programming: DNS</a>
|
||
<a class="dropdown-item" href="AppBroadcast.html"> 4.7. Application-Layer Broadcasting: DHCP</a>
|
||
<a class="dropdown-item" href="Extended4CGI.html"> 4.8. Extended Example: CGI Web Server</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 5</b></a>
|
||
<a class="dropdown-item" href="InternetOverview.html"> 5.1. The Internet and Connectivity</a>
|
||
<a class="dropdown-item" href="AppLayer.html"> 5.2. Application Layer: Overlay Networks</a>
|
||
<a class="dropdown-item" href="TransLayer.html"> 5.3. Transport Layer</a>
|
||
<a class="dropdown-item" href="NetSec.html"> 5.4. Network Security Fundamentals</a>
|
||
<a class="dropdown-item" href="NetLayer.html"> 5.5. Network Layer: IP</a>
|
||
<a class="dropdown-item" href="LinkLayer.html"> 5.6. Link Layer</a>
|
||
<a class="dropdown-item" href="Wireless.html"> 5.7. Wireless Connectivity: Wi-Fi, Bluetooth, and Zigbee</a>
|
||
<a class="dropdown-item" href="Extended5DNS.html"> 5.8. Extended Example: DNS client</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 6</b></a>
|
||
<a class="dropdown-item" href="ThreadsOverview.html"> 6.1. Concurrency with Multithreading</a>
|
||
<a class="dropdown-item" href="ProcVThreads.html"> 6.2. Processes vs. Threads</a>
|
||
<a class="dropdown-item" href="RaceConditions.html"> 6.3. Race Conditions and Critical Sections</a>
|
||
<a class="dropdown-item" href="POSIXThreads.html"> 6.4. POSIX Thread Library</a>
|
||
<a class="dropdown-item" href="ThreadArgs.html"> 6.5. Thread Arguments and Return Values</a>
|
||
<a class="dropdown-item" href="ImplicitThreads.html"> 6.6. Implicit Threading and Language-based Threads</a>
|
||
<a class="dropdown-item" href="Extended6Input.html"> 6.7. Extended Example: Keyboard Input Listener</a>
|
||
<a class="dropdown-item" href="Extended6Primes.html"> 6.8. Extended Example: Concurrent Prime Number Search</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 7</b></a>
|
||
<a class="dropdown-item" href="SynchOverview.html"> 7.1. Synchronization Primitives</a>
|
||
<a class="dropdown-item" href="CritSect.html"> 7.2. Critical Sections and Peterson's Solution</a>
|
||
<a class="dropdown-item" href="Locks.html"> 7.3. Locks</a>
|
||
<a class="dropdown-item" href="Semaphores.html"> 7.4. Semaphores</a>
|
||
<a class="dropdown-item" href="Barriers.html"> 7.5. Barriers</a>
|
||
<a class="dropdown-item" href="Condvars.html"> 7.6. Condition Variables</a>
|
||
<a class="dropdown-item" href="Deadlock.html"> 7.7. Deadlock</a>
|
||
<a class="dropdown-item" href="Extended7Events.html"> 7.8. Extended Example: Event Log File</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 8</b></a>
|
||
<a class="dropdown-item" href="SynchProblemsOverview.html"> 8.1. Synchronization Patterns and Problems</a>
|
||
<a class="dropdown-item" href="SynchDesign.html"> 8.2. Basic Synchronization Design Patterns</a>
|
||
<a class="dropdown-item" href="ProdCons.html"> 8.3. Producer-Consumer Problem</a>
|
||
<a class="dropdown-item" href="ReadWrite.html"> 8.4. Readers-Writers Problem</a>
|
||
<a class="dropdown-item" href="DiningPhil.html"> 8.5. Dining Philosophers Problem and Deadlock</a>
|
||
<a class="dropdown-item" href="CigSmokers.html"> 8.6. Cigarette Smokers Problem and the Limits of Semaphores and Locks</a>
|
||
<a class="dropdown-item" href="Extended8ModExp.html"> 8.7. Extended Example: Parallel Modular Exponentiation</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 9</b></a>
|
||
<a class="dropdown-item" href="ParallelDistributedOverview.html"> 9.1. Parallel and Distributed Systems</a>
|
||
<a class="dropdown-item" href="ParVConc.html"> 9.2. Parallelism vs. Concurrency</a>
|
||
<a class="dropdown-item" href="ParallelDesign.html"> 9.3. Parallel Design Patterns</a>
|
||
<a class="dropdown-item" href="Scaling.html"> 9.4. Limits of Parallelism and Scaling</a>
|
||
<a class="dropdown-item" href="DistTiming.html"> 9.5. Timing in Distributed Environments</a>
|
||
<a class="dropdown-item" href="DistDataStorage.html"> 9.6. Reliable Data Storage and Location</a>
|
||
<a class="dropdown-item" href="DistConsensus.html"> 9.7. Consensus in Distributed Systems</a>
|
||
<a class="dropdown-item" href="Extended9Blockchain.html"> 9.8. Extended Example: Blockchain Proof-of-Work</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Appendix A</b></a>
|
||
<a class="dropdown-item" href="CLangOverview.html"> A.1. C Language Reintroduction</a>
|
||
<a class="dropdown-item" href="Debugging.html"> A.2. Documentation and Debugging</a>
|
||
<a class="dropdown-item" href="BasicTypes.html"> A.3. Basic Types and Pointers</a>
|
||
<a class="dropdown-item" href="Arrays.html"> A.4. Arrays, Structs, Enums, and Type Definitions</a>
|
||
<a class="dropdown-item" href="Functions.html"> A.5. Functions and Scope</a>
|
||
<a class="dropdown-item" href="Pointers.html"> A.6. Pointers and Dynamic Allocation</a>
|
||
<a class="dropdown-item" href="Strings.html"> A.7. Strings</a>
|
||
<a class="dropdown-item" href="FunctionPointers.html"> A.8. Function Pointers</a>
|
||
<a class="dropdown-item" href="Files.html"> A.9. Files</a>
|
||
</div>
|
||
</li>
|
||
|
||
|
||
|
||
</ul>
|
||
</div>
|
||
|
||
<ul class="navbar-nav flex-row ml-md-auto d-none d-md-flex">
|
||
<li class="nav-item"><a class="nav-link jmu-gold" href="https://w3.cs.jmu.edu/kirkpams/OpenCSF/Books/csf/source/NetSec.rst"
|
||
target="_blank" rel="nofollow">Show Source</a></li>
|
||
|
||
</ul>
|
||
</nav>
|
||
|
||
|
||
<div class="container center">
|
||
«  <a id="prevmod" href="TransLayer.html">5.3. Transport Layer</a>
|
||
  ::  
|
||
<a class="uplink" href="index.html">Contents</a>
|
||
  ::  
|
||
<a id="nextmod" href="NetLayer.html">5.5. Internet Layer: IP</a>  »
|
||
|
||
</div>
|
||
<br />
|
||
|
||
|
||
|
||
<script type="text/javascript" src="_static/js/jquery-2.1.4.min.js"></script>
|
||
<script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||
<script type="text/javascript" src="_static/js/jquery-1.11.4-ui.min.js"></script>
|
||
<script type="text/javascript" src="_static/js/forge-0.7.0.min.js"></script>
|
||
<script type="text/javascript" src="../../../JSAV/lib/jquery.transit.js"></script>
|
||
<script type="text/javascript" src="../../../JSAV/lib/raphael.js"></script>
|
||
<script type="text/javascript" src="../../../JSAV/build/JSAV-min.js"></script>
|
||
<script type="text/javascript" src="_static/js/config.js"></script>
|
||
<script type="text/javascript" src="../../../lib/odsaUtils-min.js"></script>
|
||
<script type="text/javascript" src="../../../lib/odsaMOD-min.js"></script>
|
||
<script type="text/javascript" src="_static/js/d3-4.13.0.min.js"></script>
|
||
<script type="text/javascript" src="_static/js/d3-selection-multi.v1.min.js"></script>
|
||
<script type="text/javascript" src="../../../lib/dataStructures.js"></script>
|
||
|
||
|
||
|
||
|
||
|
||
|
||
<div class="container">
|
||
|
||
<script>ODSA.SETTINGS.DISP_MOD_COMP = true;ODSA.SETTINGS.MODULE_NAME = "NetSec";ODSA.SETTINGS.MODULE_LONG_NAME = "Network Security Fundamentals";ODSA.SETTINGS.MODULE_CHAPTER = "The Internet and Connectivity"; ODSA.SETTINGS.BUILD_DATE = "2021-06-14 17:15:25"; ODSA.SETTINGS.BUILD_CMAP = false;JSAV_OPTIONS['lang']='en';JSAV_EXERCISE_OPTIONS['code']='java';</script><div class="section" id="network-security-fundamentals">
|
||
<h1>5.4. Network Security Fundamentals<a class="headerlink" href="NetSec.html#network-security-fundamentals" title="Permalink to this headline">¶</a></h1>
|
||
<p>The previous section suggested that the length and checksum calculations in UDP and TCP headers
|
||
provide rudimentary error checking. This statement should not be read to mean that either UDP or TCP
|
||
provide secure data exchange in any meaningful sense. While many people talk about <em>security</em> in a
|
||
general sense, within the domain of computer systems, security refers primarily to the ability to
|
||
provide three services: <a class="reference internal" href="Glossary.html#term-confidentiality"><span class="xref std std-term">confidentiality</span></a>, <a class="reference internal" href="Glossary.html#term-integrity"><span class="xref std std-term">integrity</span></a>, and <a class="reference internal" href="Glossary.html#term-availability"><span class="xref std std-term">availability</span></a>.</p>
|
||
<p>Confidentiality is the service that a message can be read only by an entity that is authorized to do
|
||
so. Consider the case where a person named Alice has a secret to share with Bob. Alice intends that
|
||
Bob is the only other person authorized to learn this information. Confidentiality is the guarantee
|
||
that this goal is achieved. Confidentiality would be broken if a third person, Eve <a class="footnote-reference" href="NetSec.html#f33" id="id1">[1]</a>, could
|
||
learn the secret in some way.</p>
|
||
<p>Integrity is the service that the communication is protected against unauthorized modifications.
|
||
Returning to Alice and Bob, consider a message from Alice that authorizes a bank transfer of \$1,000
|
||
to Bob’s bank account. Integrity ensures that the bank receives the correct message. Integrity would
|
||
be violated if Mallory could corrupt the message to reduce the transfer down to \$1; Bob would not
|
||
get the full expected transfer and would be rather upset. Mallory could also violate integrity by
|
||
increasing the amount to \$100,000 in an attempt to remove all of the money from Alice’s account;
|
||
Mallory may be motivated purely by the goal of harming Alice rather than intending to help Bob. Or
|
||
Mallory may try to profit off the attack by changing the account number to redirect the transfer.</p>
|
||
<p>Availability requires that authorized users are not prevented from performing authorized actions,
|
||
whether that action involves reading or modifying data. In the first case, Mallory may break the
|
||
guarantee of availability by preventing Bob from receiving the secret message that Alice sent. In
|
||
the second case, Mallory might launch a <a class="reference internal" href="Glossary.html#term-denial-of-service"><span class="xref std std-term">denial-of-service</span></a> attack against the bank to prevent
|
||
it from receiving Alice’s message authorizing the transfer.</p>
|
||
<p>Neither TCP nor UDP provide any of these three guarantees. The contents of the application-layer
|
||
payload are not hidden or scrambled in any way, so there is no guarantee of confidentiality. The
|
||
checksum calculation can be trivially manipulated to break integrity without detection: change the
|
||
order of the bytes in the segment. Checksums are essentially just addition, and it is a fundamental
|
||
tenet of basic arithmetic that 3 + 5 and 5 + 3 produce the same result. Although TCP aims to provide
|
||
reliable data transport, its services do not meet the standard required for availability. TCP’s
|
||
reliability consists of trying again when an expected segment does not arrive; this second (and
|
||
third…) attempt can easily fail again in a successful denial-of-service. Consequently, neither TCP
|
||
nor UDP guarantee any of these security services.</p>
|
||
<p><a class="reference internal" href="Glossary.html#term-cryptography"><span class="xref std std-term">Cryptography</span></a> is a specialized field that uses a variety of techniques—typically advanced
|
||
mathematical concepts—to create secure communication channels. This section provides a very brief
|
||
overview of two cryptographic techniques that are relevant to the current discussion.
|
||
<a class="reference internal" href="Glossary.html#term-encryption"><span class="xref std std-term">Encryption</span></a> involves encoding a message (the <a class="reference internal" href="Glossary.html#term-plaintext"><span class="xref std std-term">plaintext</span></a>) into random-looking binary
|
||
string (the <a class="reference internal" href="Glossary.html#term-ciphertext"><span class="xref std std-term">ciphertext</span></a>) in a way that allows the process to be reversed. Encryption, then,
|
||
provides confidentiality by hiding the secret message in an unreadable way. <a class="reference internal" href="Glossary.html#term-cryptographic-hash-function"><span class="xref std std-term">Cryptographic
|
||
hash functions</span></a>, on the other hand, encode the message into a
|
||
fixed-length ciphertext that does not allow the plaintext to be recovered. Cryptographic hash
|
||
functions provide integrity, as they are designed to prevent adversaries from finding a corrupted
|
||
plaintext that produces the same ciphertext.</p>
|
||
<p>Neither of these techniques guarantees availability, which is extremely difficult to provide. To
|
||
illustrate an availability attack, recall the three steps of the TCP handshake. In a <a class="reference internal" href="Glossary.html#term-syn-flood"><span class="xref std std-term">SYN
|
||
flood</span></a>, an adversary repeatedly sends SYN packets to initiate the handshake and open a connection;
|
||
as each of these arrive at the server, the server allocates internal data structures to handle the
|
||
request. However, the adversary never completes the handshake for any of these requests or closes
|
||
the connection. Consequently, the server eventually runs out of memory or other resources,
|
||
preventing legitimate users from connecting. Detecting these types of attacks is not
|
||
straightforward, making availability a challenge. To make matters worse, availability is often at
|
||
odds with confidentiality and integrity. Providing confidentiality or integrity can make
|
||
availability more difficult, and vice versa. As our goal is to focus on the basic principles of
|
||
security, we limit our discussion to the basics of encryption and cryptographic hash functions;
|
||
interested readers should explore the recommended readings for more information.</p>
|
||
<div class="section" id="symmetric-key-encryption">
|
||
<h2>5.4.1. Symmetric Key Encryption<a class="headerlink" href="NetSec.html#symmetric-key-encryption" title="Permalink to this headline">¶</a></h2>
|
||
<p>The process of encryption involves combining a plaintext message with a <a class="reference internal" href="Glossary.html#term-cryptographic-key"><span class="xref std std-term">key</span></a> to create a
|
||
ciphertext that looks like an unreadable series of random bits. In a perfect encryption system
|
||
<a class="footnote-reference" href="NetSec.html#f34" id="id2">[2]</a>, when Alice sends a ciphertext to Bob, Eve learns nothing about the plaintext. However, Bob
|
||
will be able to decrypt the message back into its plaintext form with the corresponding key.</p>
|
||
<p>Encryption and decryption are often written in a formal notation, using $m$ and $c$ to refer to the
|
||
plaintext message and ciphertext, along with $e_K$ and $d_K$ to denote encryption and decryption
|
||
functions using a particular key. This notation leads to the following generic equations:</p>
|
||
<center>
|
||
<span class="math inline">$\large c = e_K(m) \hspace{1.5in} m = d_K(c)$</span>
|
||
</center>
|
||
<br /><p>There are two distinct styles of encryption that are in common use. In <a class="reference internal" href="Glossary.html#term-symmetric-key-cryptography"><span class="xref std std-term">symmetric key</span></a>
|
||
encryption, the same key is required for both encryption and decryption. That is, Alice and Bob must
|
||
have an agreement before exchanging the ciphertext of what the key is. In contrast, <a class="reference internal" href="Glossary.html#term-public-key-cryptography"><span class="xref std std-term">public
|
||
key</span></a> encryption uses two distinct keys for encryption and decryption. In this <a class="reference internal" href="Glossary.html#term-key-pair"><span class="xref std std-term">key pair</span></a>, one
|
||
(public) key can be made publicly available while the other (private) must remain secret. For
|
||
instance, Alice can use Bob’s public key to encrypt a message, allowing only Bob to decrypt it using
|
||
his private key. On the other hand, Alice can encrypt a message using her private key, allowing Bob
|
||
or anyone else to decrypt it using Alice’s public key. This latter approach is the basic idea behind
|
||
<a class="reference internal" href="Glossary.html#term-cryptographic-signature"><span class="xref std std-term">cryptographic signatures</span></a>, as it provides a way to confirm that a message truly came from
|
||
Alice; if the message can be decrypted with Alice’s public key, it must have been encrypted with her
|
||
private key (that only she knows).</p>
|
||
<p>The most commonly used symmetric key cipher in modern practice is the <a class="reference internal" href="Glossary.html#term-advanced-encryption-standard"><span class="xref std std-term">Advanced Encryption
|
||
Standard</span></a> (AES). <a class="reference internal" href="Glossary.html#term-national-institute-of-standards-and-technologies"><span class="xref std std-term">National Institute of Standards and Technologies</span></a> (NIST)—a part of the U.S.
|
||
federal government that defines cryptographic and other technical standards—selected AES as a
|
||
replacement for older symmetric key ciphers when those were found to have weaknesses. AES uses a
|
||
technique called the <em>Rijndael block cipher</em>, breaking the plaintext into a sequence of
|
||
128-bit blocks that are each encrypted. AES has three variations based on the length of the key
|
||
(128, 192, or 256 bits long).</p>
|
||
<div class="figure mb-2 align-right" id="id12" style="width: 35%">
|
||
<span id="netsecaes"></span><a class="reference internal image-reference" href="_images/CSF-Images.5.5.png"><img class="p-3 mb-2 align-center border border-dark rounded-lg" alt="The iterative structure of AES" src="_images/CSF-Images.5.5.png" style="width: 90%;" /></a>
|
||
<p class="caption align-center px-3"><span class="caption-text"> Figure 5.4.1: The iterative structure of AES</span></p>
|
||
</div>
|
||
<p>Rather than a single procedure, AES encryption is an iterative process that uses several keys—one
|
||
per round of the iteration. <a href="NetSec.html#netsecaes">Figure 5.4.1</a> illustrates the overall structure of AES. The
|
||
original 128-, 192-, or 256-bit key is first used as the input to a <code class="docutils literal notranslate"><span class="pre">KeyExpansion</span></code> algorithm,
|
||
generating a <a class="reference internal" href="Glossary.html#term-key-schedule"><span class="xref std std-term">key schedule</span></a> of multiple round keys. Then, for each 128-bit block of the
|
||
plaintext, AES arranges the bits into a 4x4 matrix of bytes, which represents the state of the
|
||
block. Within each round, the round key is combined (<code class="docutils literal notranslate"><span class="pre">AddRoundKey</span></code>) with the <em>state</em> by applying
|
||
the bitwise XOR operation. Next, the <code class="docutils literal notranslate"><span class="pre">SubBytes</span></code> step replaces the contents by looking each byte up
|
||
in a substitution box (S-box); for instance, any byte that contains the value 13 might be replaced
|
||
with the value 275. The <code class="docutils literal notranslate"><span class="pre">ShiftRows</span></code> step rotates each row by a different number of places to the
|
||
left (e.g., row 0 stays intact, row 1 bytes shift one place to the left, and so on). The
|
||
<code class="docutils literal notranslate"><span class="pre">MixColumns</span></code> applies a linear transformation that mixes the placement of bits within a single
|
||
column. To decrypt an AES ciphertext, the same key schedule is used, but in reverse. The steps of
|
||
each round are also reversed.</p>
|
||
<p>The strength of symmetric key algorithms like AES derives from the strong probabilistic guarantees
|
||
associated created by non-linear operations. For example, consider the XOR operation. If the output
|
||
of a one-bit XOR operation is 1, there are two equally likely possibilities: either the plaintext
|
||
bit is 0 and the key is 1, or the plaintext is 1 and the key is 0. This approach is the basis of a
|
||
<a class="reference internal" href="Glossary.html#term-one-time-pad"><span class="xref std std-term">one-time pad</span></a>, in which all of the bits of a plaintext are XORed with a random key that is
|
||
the same length as the input. Under many ideal assumptions, one-time pads achieve <a class="reference internal" href="Glossary.html#term-information-theoretic-security"><span class="xref std std-term">information
|
||
theoretic security</span></a>, which means that an adversary trying to break the code can only guess. Every
|
||
bit of the key is equally likely to be a 1 or a 0. Regardless of how long an adversary’s program
|
||
runs, the probability of each bit never changes, and the program cannot make progress toward
|
||
breaking the code. In essence, one-time pads are perfectly secure in theory; in practice, they are
|
||
not, because the plaintext messages cannot achieve the level of randomness required. For example,
|
||
assume that Eve knows Alice sent either “Hello” or “Goodbye” with a one-time pad; Eve does not need
|
||
to know the key, because she can determine the message by examining just the length of the
|
||
ciphertext. Hence, practical symmetric key approaches like AES combine XOR with other operations
|
||
that further obscure the message.</p>
|
||
<p>The operations used in AES are very fast, measured on the scale of CPU cycles. The full encryption
|
||
process for a single block requires 10, 12, or 14 rounds (based on the key size). Consequently, AES
|
||
can encrypt a significant amount of data very efficiently. The only problem is how should Alice and
|
||
Bob determine what key to use, particularly if they have never spoken before? For instance, when you
|
||
use a web browser to visit your school’s or bank’s website for the first time, the browser and
|
||
server need to determine a key to use. As a complicating factor, depending on more advanced
|
||
characteristics of the algorithm, it may be necessary to ensure the key has not been used before.</p>
|
||
<div class="topic border border-dark rounded-lg bg-light px-2 mb-3">
|
||
<div class="figure align-left">
|
||
<a class="reference internal image-reference" href="_images/CSF-Images-Library.png"><img alt="Decorative C library image" src="_images/CSF-Images-Library.png" style="width: 100%;" /></a>
|
||
</div>
|
||
<p class="topic-title first pt-2 mb-1">C OpenSSL library functions – <openssl/evp.h></p><hr class="mt-1" />
|
||
<p>This is not a standard library, so you may need to use the -I and -L compiler flags.</p>
|
||
<dl class="docutils">
|
||
<dt><code class="docutils literal notranslate"><span class="pre">EVP_CIPHER_CTX</span> <span class="pre">*EVP_CIPHER_CTX_new</span> <span class="pre">(void);</span></code></dt>
|
||
<dd>Creates a new context for encryption or decryption.</dd>
|
||
<dt><code class="docutils literal notranslate"><span class="pre">void</span> <span class="pre">EVP_CIPHER_CTX_free</span> <span class="pre">(EVP_CIPHER_CTX</span> <span class="pre">*ctx);</span></code></dt>
|
||
<dd>Frees up resources allocated to a context.</dd>
|
||
<dt><code class="docutils literal notranslate"><span class="pre">int</span> <span class="pre">EVP_EncryptInit</span> <span class="pre">(EVP_CIPHER_CTX</span> <span class="pre">*ctx,</span> <span class="pre">const</span> <span class="pre">EVP_CIPHER</span> <span class="pre">*cipher,</span> <span class="pre">const</span> <span class="pre">unsigned</span> <span class="pre">char</span> <span class="pre">*key,</span> <span class="pre">const</span> <span class="pre">unsigned</span> <span class="pre">char</span> <span class="pre">*iv);</span></code></dt>
|
||
<dd>Initializes the context to use a cipher given a key and initialization vector.</dd>
|
||
<dt><code class="docutils literal notranslate"><span class="pre">int</span> <span class="pre">EVP_EncryptUpdate</span> <span class="pre">(EVP_CIPHER_CTX</span> <span class="pre">*ctx,</span> <span class="pre">unsigned</span> <span class="pre">char</span> <span class="pre">*out,</span> <span class="pre">int</span> <span class="pre">*outl,</span> <span class="pre">const</span> <span class="pre">unsigned</span> <span class="pre">char</span> <span class="pre">*in,</span> <span class="pre">int</span> <span class="pre">inl);</span></code></dt>
|
||
<dd>Updates the encryption computation for the plaintext chunk in, writing the results to out.</dd>
|
||
<dt><code class="docutils literal notranslate"><span class="pre">int</span> <span class="pre">EVP_EncryptFinal</span> <span class="pre">(EVP_CIPHER_CTX</span> <span class="pre">*ctx,</span> <span class="pre">unsigned</span> <span class="pre">char</span> <span class="pre">*out,</span> <span class="pre">int</span> <span class="pre">*outl);</span></code></dt>
|
||
<dd>Writes the final ciphertext into the buffer out.</dd>
|
||
</dl>
|
||
</div>
|
||
<p><a class="reference external" href="NetSec.html#cl5-2">Code Listing 5.2</a> shows the basic structure of initializing an encryption context using
|
||
the OpenSSL <code class="docutils literal notranslate"><span class="pre">crypto</span></code> library. <a class="footnote-reference" href="NetSec.html#f35" id="id3">[3]</a> All symmetric key ciphers require specifying a <em>cipher
|
||
mode</em>. In this example, we are using cipher block chaining (CBC), a very widely used mode.</p>
|
||
<div class="highlight-c border border-dark rounded-lg bg-light px-0 mb-3 notranslate" id="cl5-2"><table class="highlighttable"><tr><td class="linenos px-0 mx-0"><div class="linenodiv"><pre class="mb-0"> 1
|
||
2
|
||
3
|
||
4
|
||
5
|
||
6
|
||
7
|
||
8
|
||
9
|
||
10
|
||
11
|
||
12
|
||
13</pre></div></td><td class="code"><div class="highlight bg-light"><pre class="mb-0"><span></span><span class="cm">/* Code Listing 5.2:</span>
|
||
<span class="cm"> Create an encryption context for AES-256 in CBC mode</span>
|
||
<span class="cm"> */</span>
|
||
|
||
<span class="cm">/* Create REALLY BAD 256-bit key and initialization vectors. For </span>
|
||
<span class="cm"> AES-256, key must be 256 bits (32 bytes) and initialization</span>
|
||
<span class="cm"> vector is 128 bits (16 bytes). */</span>
|
||
<span class="kt">unsigned</span> <span class="kt">char</span> <span class="o">*</span><span class="n">key</span> <span class="o">=</span> <span class="p">(</span><span class="kt">unsigned</span> <span class="kt">char</span> <span class="o">*</span><span class="p">)</span> <span class="s">"aaaabbbbccccddddeeeeffffgggghhhh"</span><span class="p">;</span>
|
||
<span class="kt">unsigned</span> <span class="kt">char</span> <span class="o">*</span><span class="n">iv</span> <span class="o">=</span> <span class="p">(</span><span class="kt">unsigned</span> <span class="kt">char</span> <span class="o">*</span><span class="p">)</span> <span class="s">"iiiijjjjkkkkllll"</span><span class="p">;</span>
|
||
|
||
<span class="cm">/* Set up the context and initialize it */</span>
|
||
<span class="n">EVP_CIPHER_CTX</span> <span class="o">*</span><span class="n">ctx</span> <span class="o">=</span> <span class="n">EVP_CIPHER_CTX_new</span><span class="p">();</span>
|
||
<span class="n">EVP_EncryptInit</span> <span class="p">(</span><span class="n">ctx</span><span class="p">,</span> <span class="n">EVP_aes_256_cbc</span> <span class="p">(),</span> <span class="n">key</span><span class="p">,</span> <span class="n">iv</span><span class="p">);</span>
|
||
</pre></div>
|
||
</td></tr></table></div>
|
||
<p><a class="reference external" href="NetSec.html#cl5-3">Code Listing 5.3</a> illustrates how to encrypt a plaintext message using the initialized
|
||
context. <code class="docutils literal notranslate"><span class="pre">EVP_EncryptUpdate()</span></code> can be called repeatedly as needed for long messages. For instance,
|
||
if the plaintext consisted of a large file stored on disk, the file could be read into memory in
|
||
small chunks at a time; each chunk would then be passed to <code class="docutils literal notranslate"><span class="pre">EVP_EncryptUpdate()</span></code> accordingly.
|
||
<a class="reference external" href="NetSec.html#cl5-3">Code Listing 5.3</a> only requires a single call on line 12, as the <code class="docutils literal notranslate"><span class="pre">plaintext</span></code> is short.
|
||
Line 18 writes the final result into the allocated buffer <code class="docutils literal notranslate"><span class="pre">ciphertext</span></code> buffer. Note that this data
|
||
is not in a printable format, so an appropriate encoding (such as Base64) will need to be used for
|
||
many applications.</p>
|
||
<div class="highlight-c border border-dark rounded-lg bg-light px-0 mb-3 notranslate" id="cl5-3"><table class="highlighttable"><tr><td class="linenos px-0 mx-0"><div class="linenodiv"><pre class="mb-0"> 1
|
||
2
|
||
3
|
||
4
|
||
5
|
||
6
|
||
7
|
||
8
|
||
9
|
||
10
|
||
11
|
||
12
|
||
13
|
||
14
|
||
15
|
||
16
|
||
17
|
||
18
|
||
19
|
||
20
|
||
21
|
||
22
|
||
23
|
||
24
|
||
25</pre></div></td><td class="code"><div class="highlight bg-light"><pre class="mb-0"><span></span><span class="cm">/* Code Listing 5.3:</span>
|
||
<span class="cm"> Encrypting a string using the AES context from Code Listing 5.1</span>
|
||
<span class="cm"> */</span>
|
||
|
||
<span class="kt">char</span> <span class="o">*</span><span class="n">plaintext</span> <span class="o">=</span> <span class="s">"Hello world"</span><span class="p">;</span>
|
||
<span class="kt">int</span> <span class="n">plain_length</span> <span class="o">=</span> <span class="mi">12</span><span class="p">;</span>
|
||
<span class="kt">unsigned</span> <span class="kt">char</span> <span class="n">ciphertext</span><span class="p">[</span><span class="mi">128</span><span class="p">];</span>
|
||
<span class="n">memset</span> <span class="p">(</span><span class="n">ciphertext</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="k">sizeof</span> <span class="p">(</span><span class="n">ciphertext</span><span class="p">));</span>
|
||
<span class="kt">int</span> <span class="n">length</span> <span class="o">=</span> <span class="mi">0</span><span class="p">,</span> <span class="n">cipher_length</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
|
||
|
||
<span class="cm">/* Update the encryption context based on the plaintext */</span>
|
||
<span class="n">EVP_EncryptUpdate</span> <span class="p">(</span><span class="n">ctx</span><span class="p">,</span> <span class="n">ciphertext</span><span class="p">,</span> <span class="o">&</span><span class="n">length</span><span class="p">,</span> <span class="p">(</span><span class="kt">unsigned</span> <span class="kt">char</span> <span class="o">*</span><span class="p">)</span><span class="n">plaintext</span><span class="p">,</span>
|
||
<span class="n">plain_length</span><span class="p">);</span>
|
||
<span class="n">cipher_length</span> <span class="o">=</span> <span class="n">length</span><span class="p">;</span>
|
||
|
||
<span class="cm">/* Finalize the context, which may require appending some data to</span>
|
||
<span class="cm"> the end of the ciphertext buffer */</span>
|
||
<span class="n">EVP_EncryptFinal</span> <span class="p">(</span><span class="n">ctx</span><span class="p">,</span> <span class="n">ciphertext</span> <span class="o">+</span> <span class="n">length</span><span class="p">,</span> <span class="o">&</span><span class="n">length</span><span class="p">);</span>
|
||
<span class="n">cipher_length</span> <span class="o">+=</span> <span class="n">length</span><span class="p">;</span>
|
||
<span class="n">EVP_CIPHER_CTX_free</span> <span class="p">(</span><span class="n">ctx</span><span class="p">);</span>
|
||
|
||
<span class="n">printf</span> <span class="p">(</span><span class="s">"Plaintext is:</span><span class="se">\n</span><span class="s">"</span><span class="p">);</span>
|
||
<span class="n">BIO_dump_fp</span> <span class="p">(</span><span class="n">stdout</span><span class="p">,</span> <span class="p">(</span><span class="k">const</span> <span class="kt">char</span> <span class="o">*</span><span class="p">)</span><span class="n">plaintext</span><span class="p">,</span> <span class="n">plain_length</span><span class="p">);</span>
|
||
<span class="n">printf</span> <span class="p">(</span><span class="s">"Ciphertext is:</span><span class="se">\n</span><span class="s">"</span><span class="p">);</span>
|
||
<span class="n">BIO_dump_fp</span> <span class="p">(</span><span class="n">stdout</span><span class="p">,</span> <span class="p">(</span><span class="k">const</span> <span class="kt">char</span> <span class="o">*</span><span class="p">)</span><span class="n">ciphertext</span><span class="p">,</span> <span class="n">cipher_length</span><span class="p">);</span>
|
||
</pre></div>
|
||
</td></tr></table></div>
|
||
<p>Assuming OpenSSL is installed in the directories shown, we can combine <a class="reference external" href="NetSec.html#cl5-2">Code Listings 5.2</a>
|
||
and <a class="reference external" href="NetSec.html#cl5-3">5.3</a> into a single <code class="docutils literal notranslate"><span class="pre">encrypt.c</span></code> file, then can compile and run this program on macOS
|
||
as follows (Linux should not need the <code class="docutils literal notranslate"><span class="pre">-L</span></code> and <code class="docutils literal notranslate"><span class="pre">-I</span></code> flags, as OpenSSL is typically installed in
|
||
the standard locations checked by the compiler). Lines 23 and 25 use the OpenSSL <code class="docutils literal notranslate"><span class="pre">BIO_dump_fp()</span></code>
|
||
function to write the <code class="docutils literal notranslate"><span class="pre">plaintext</span></code> and <code class="docutils literal notranslate"><span class="pre">ciphertext</span></code> buffers out to <code class="docutils literal notranslate"><span class="pre">STDOUT</span></code> in a format similar
|
||
to <code class="docutils literal notranslate"><span class="pre">hexdump</span></code>.</p>
|
||
<div class="highlight-none border border-dark rounded-lg bg-light px-2 mb-3 notranslate"><div class="highlight bg-light"><pre class="mb-0"><span></span>$ gcc -o encrypt encrypt.c -L/usr/local/opt/openssl@1.1/lib \
|
||
> -I/usr/local/opt/openssl@1.1/include -lcrypto
|
||
$ ./encrypt
|
||
Plaintext is:
|
||
0000 - 48 65 6c 6c 6f 20 77 6f-72 6c 64 00 Hello world.
|
||
Ciphertext is:
|
||
0000 - a8 46 db 10 77 55 c8 91-18 19 22 b4 73 1a d2 fc .F..wU....".s...
|
||
</pre></div>
|
||
</div>
|
||
<p>Decrypting messages uses the same structure as <a class="reference external" href="NetSec.html#cl5-2">Code Listings 5.2</a> and <a class="reference external" href="NetSec.html#cl5-3">5.3</a>.
|
||
The only difference is the function names change accordingly, such as <code class="docutils literal notranslate"><span class="pre">EVP_DecryptUpdate()</span></code>. The
|
||
order of the arguments in each of these functions is identical to the encryption versions.</p>
|
||
<div class="topic border border-dark rounded-lg alert-danger px-2 mb-3">
|
||
<div class="figure align-left">
|
||
<a class="reference internal image-reference" href="_images/CSF-Images-BugWarning.png"><img alt="Decorative bug warning" src="_images/CSF-Images-BugWarning.png" style="width: 90%;" /></a>
|
||
</div>
|
||
<p class="topic-title first pt-2 mb-1">Bug Warning</p><hr class="mt-1" />
|
||
<p><a class="reference external" href="NetSec.html#cl5-2">Code Listings 5.2</a> and <a class="reference external" href="NetSec.html#cl5-3">5.3</a> omitted error checking on the calls to the OpenSSL
|
||
library functions for simplicity. In practice, every OpenSSL function’s return type should be
|
||
checked to ensure that the encryption or decryption is working successfully. Failure to do so could
|
||
cause a segmentation fault and crash the program.</p>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="public-key-encryption">
|
||
<h2>5.4.2. Public Key Encryption<a class="headerlink" href="NetSec.html#public-key-encryption" title="Permalink to this headline">¶</a></h2>
|
||
<p>Public key encryption provides a solution to the problem of <a class="reference internal" href="Glossary.html#term-key-exchange-protocol"><span class="xref std std-term">key exchange</span></a>. With public key
|
||
encryption, one of the hosts can generate a fresh (unused) AES key, then encrypt the key with the
|
||
other host’s public key. That is, Alice might generate a <a class="reference internal" href="Glossary.html#term-session-key"><span class="xref std std-term">session key</span></a> $K$ to use for AES,
|
||
then send Bob the message $c = e_P (K)$, using Bob’s public key $P$. Bob can then use his secret key $S$:</p>
|
||
<center>
|
||
<span class="math inline">$\large d_S(c) = d_S(e_P(K)) = K$</span>
|
||
</center>
|
||
<br /><p>Unlike symmetric key, public key encryption is not derived from operations like XOR that achieve
|
||
information theoretic security. Instead, public key systems strive for <a class="reference internal" href="Glossary.html#term-semantic-security"><span class="xref std std-term">semantic security</span></a>
|
||
guarantees that reduce the adversary to having a <em>negligible</em> probability of successfully guessing
|
||
the key or plaintext. The notion of negligible probability means that the encryption procedure leaks
|
||
a small amount of information (i.e., it provides hints to the adversary), but this leakage is so
|
||
miniscule that a successful guess in a reasonable amount of time is absurdly unlikely. Given enough
|
||
time (think in terms of billions of years), a successful attack is possible, but the adversary would
|
||
be long dead before that point. Semantic security is created by a number of mathematical problems
|
||
that are known to be difficult to solve. Some of these schemes involve advanced number theory
|
||
concepts, such as elliptic curves, prime number factorization, and discrete logarithms.</p>
|
||
<p>To illustrate the basic idea, consider the premise of the <a class="reference internal" href="Glossary.html#term-rsa-cryptosystem"><span class="xref std std-term">RSA</span></a> (Rivest-Shamir-Adleman)
|
||
algorithm. To prepare for RSA encryption, the application chooses two large prime numbers $p$ and
|
||
$q$; $p$ and $q$ remain secret, while their product $n = pq$ is made public. The public and private
|
||
keys, denoted $e$ and $d$ in this scenario, are chosen to have a particular property. For any number
|
||
$m$ (the plaintext message):</p>
|
||
<center>
|
||
<span class="math inline">$\large (m^e)^d \equiv (m^d)^e \equiv m \mbox{ mod } n$</span>
|
||
</center>
|
||
<br /><p>That is, when e and d are used as two consecutive exponents and the result is calculated modulo the
|
||
(public) $n$ value, the original value $m$ is returned. In effect, $e$ and $d$ cancel each other out
|
||
in modular exponentiation. Note that both $n$ and $e$ can be made public; an adversary with no
|
||
knowledge of $d$ is cannot efficiently compute $m$ after observing the ciphertext $c = m^e \mod n$.
|
||
Additionally, observing the ciphertext $c’ = m^d \mod n$ does not immediately reveal the value of
|
||
$d$, even if both $m$ and $n$ are known.</p>
|
||
<div class="topic border border-dark rounded-lg bg-light px-2 mb-3">
|
||
<div class="figure align-left">
|
||
<a class="reference internal image-reference" href="_images/CSF-Images-Example.png"><img alt="Decorative example icon" src="_images/CSF-Images-Example.png" style="width: 100%;" /></a>
|
||
</div>
|
||
<p class="topic-title first pt-2 mb-1">Example 5.4.1 </p><hr class="mt-1" />
|
||
<p>As a simple example of the basic functioning of RSA, consider $n = 55$ ($p = 5, q = 11$). Based on
|
||
these parameters, we can let $e = 3$ and $d = 7$ (the rationale for this choice is beyond the
|
||
current scope of this text). If we choose our <em>message</em> $m = 6$, then we can compute $m^e = 63 = 216
|
||
≡ 51 \mod 55$. Then, $51^{7} = 897,410,677,851$, which is equivalent to $6 \mod 55$. Hence, the
|
||
values $e = 3$ and $d = 7$ are inverses for modular exponentiation, given $n = 55$. We could
|
||
arbitrarily consider one of these values as our private key and one to release as a public key,
|
||
although their size is absurdly small. (This example could be impelemtned with 8-bit unsigned
|
||
integers, whereas values in real implementations of RSA would be on the scale of 4096-bit unsigned
|
||
integers.)</p>
|
||
</div>
|
||
<p>For completeness, <strong>this particular form of RSA should never be used in practice</strong>. Just as AES
|
||
required more operations than just XOR, making RSA practical requires more work than just modular
|
||
exponentiation to achieve semantic security. Our goal here is to provide an illustrative example of
|
||
the key idea of public key cryptography: Posting one of the keys publicly allows anyone to encrypt a
|
||
message that can only be read by someone with the corresponding private key. In contrast to
|
||
symmetric key, public key encryption is extremely slow, and it is not practical for encrypting large
|
||
amounts of data; however, public key encryption can protect small pieces of data, such as 128-bit
|
||
session keys, to allow hosts to set up a secure communication channel.</p>
|
||
</div>
|
||
<div class="section" id="cryptographic-hash-functions">
|
||
<h2>5.4.3. Cryptographic Hash Functions<a class="headerlink" href="NetSec.html#cryptographic-hash-functions" title="Permalink to this headline">¶</a></h2>
|
||
<p>Both symmetric key and public key encryption focus on providing confidentiality guarantees for
|
||
security. Once a message has been encrypted into ciphertext, it can only be read by someone who has
|
||
the corresponding decryption key. To provide integrity, though, we need a different technique.
|
||
Cryptographic hash functions serve this purpose by taking an arbitrary-length input message and
|
||
running it through a compression algorithm to produce a fixed-length result.</p>
|
||
<p>In essence, a cryptographic hash function is a one-way function to map any input to an unpredictable
|
||
bit string. Readers with a background in data structures may be familiar with the concept of hash
|
||
functions as used in hash tables; for instance, a simple hash function would simply apply a modulus
|
||
operation to an input value. Cryptographic hash functions are very different. Cryptographic hash
|
||
functions are designed to be intentionally slow, as the goal is to avoid the discovery of
|
||
<a class="reference internal" href="Glossary.html#term-collision"><span class="xref std std-term">collisions</span></a>, two inputs that share the same hash. The <a class="reference internal" href="Glossary.html#term-avalanche-effect"><span class="xref std std-term">avalanche effect</span></a> contributes to
|
||
this goal, as flipping a single bit in the input produces a very different final result.</p>
|
||
<div class="figure mb-2 align-right" id="id13" style="width: 45%">
|
||
<span id="netsecsha"></span><a class="reference internal image-reference" href="_images/CSF-Images.5.6.png"><img class="p-3 mb-2 align-center border border-dark rounded-lg" alt="One round of SHA-2 compression. Image source: Wikipedia (recreated)" src="_images/CSF-Images.5.6.png" style="width: 95%;" /></a>
|
||
<p class="caption align-center px-3"><span class="caption-text"> Figure 5.4.5: One round of SHA-2 compression. Image source: Wikipedia (recreated)</span></p>
|
||
</div>
|
||
<p><a href="NetSec.html#netsecsha">Figure 5.4.5</a> illustrates the compression technique used in the SHA-2, one currently recommended family of cryptographic hash functions. The message to be hashed is broken up into a series of chunks denoted as $W_t$. that are combined with a series of constants $K_t$. The running hash value—which might be 224, 256, 384, or 512 bits in length—is broken into eight smaller blocks of equal length, labeled as <code class="docutils literal notranslate"><span class="pre">A-H</span></code> at the top. Some blocks (<code class="docutils literal notranslate"><span class="pre">A-C</span></code> and <code class="docutils literal notranslate"><span class="pre">E-G</span></code>) are shifted to different locations (<code class="docutils literal notranslate"><span class="pre">B-D</span></code> and <code class="docutils literal notranslate"><span class="pre">F-H</span></code>) in the output. The output <code class="docutils literal notranslate"><span class="pre">A</span></code> and <code class="docutils literal notranslate"><span class="pre">E</span></code> blocks are the result of combining the eight input blocks through various operations, including XOR, bit shifting, logical operators, and one’s complement addition. The result is then fed back in to the compression algorithm; this process is repeated either 64 or 80 times, depending on the SHA-2 variant used.</p>
|
||
<p>Note that the compression described above only works on a single block (e.g., 256 bits) of data. The full SHA-2 procedure breaks the original, arbitrary-length message into a sequence of these blocks. At each step, the output from compressing the current block is combined with the next input block, creating a chained structure known as a <a class="reference internal" href="Glossary.html#term-merkle-damgard-construction"><span class="xref std std-term">Merkle-Damgård construction</span></a>. The Merkle-Damgård construction is susceptible to an attack that involves extending the hash calculation with more data. That is, once the output of the cryptographic hash is computed, the adversary can continue to append more data until a collision is found.</p>
|
||
<div class="figure mb-2 align-right" id="id14" style="width: 30%">
|
||
<span id="netsecmte"></span><a class="reference internal image-reference" href="_images/CSF-Images.5.7.png"><img class="p-3 mb-2 align-center border border-dark rounded-lg" alt="MAC-then-Encrypt structure used in TLS. Image source: Wikipedia (recreated)" src="_images/CSF-Images.5.7.png" style="width: 90%;" /></a>
|
||
<p class="caption align-center px-3"><span class="caption-text"> Figure 5.4.6: MAC-then-Encrypt structure used in TLS. Image source: Wikipedia (recreated)</span></p>
|
||
</div>
|
||
<p>At the time of this writing, SHA-2 is still recommended for use (unlike SHA-0 and SHA-1), as there
|
||
is no known practical attack. However, given the susceptibility of the Merkle-Damgård construction
|
||
to this type of attack, NIST has also released <a class="reference internal" href="Glossary.html#term-sha-3"><span class="xref std std-term">SHA-3</span></a>. SHA-3 replaces the Merkle-Damgård
|
||
construction with a different <a class="reference internal" href="Glossary.html#term-sponge-construction"><span class="xref std std-term">sponge construction</span></a>. NIST recommends SHA-3 as an available
|
||
alternative—not a replacement—for SHA-2, and both remain in use.</p>
|
||
<p>On their own, cryptographic hash functions provide a basic mechanism for integrity. If a message $m$
|
||
is known and someone claims that the hash value $H(m)$ is the correct hash value, the truth of this
|
||
statement can be easily confirmed. However, that construction alone does not allow anyone to claim
|
||
to be the author if $m$. Instead, the cryptographic hash function must combine $m$ with a key.
|
||
<a href="NetSec.html#netsecmte">Figure 5.4.6</a> shows one technique for doing this, known as <a class="reference internal" href="Glossary.html#term-mac-then-encrypt"><span class="xref std std-term">MAC-then-Encrypt</span></a>
|
||
(MtE). The first step is to use a <a class="reference internal" href="Glossary.html#term-keyed-cryptographic-hash-function"><span class="xref std std-term">keyed cryptographic hash function</span></a> that combines the
|
||
plaintext with a secret key to compute a <a class="reference internal" href="Glossary.html#term-message-authentication-code"><span class="xref std std-term">message authentication code</span></a> (MAC). The MAC is then
|
||
appended to the plaintext, and the resulting message is encrypted. MtE provides guarantees of both
|
||
confidentiality and integrity, but it also provides a claim of <a class="reference internal" href="Glossary.html#term-authenticity"><span class="xref std std-term">authenticity</span></a> about
|
||
authorship—only someone with the key could generate the MAC and ciphertext.</p>
|
||
<div class="topic border border-dark rounded-lg bg-light px-2 mb-3">
|
||
<div class="figure align-left">
|
||
<a class="reference internal image-reference" href="_images/CSF-Images-Library.png"><img alt="Decorative C library image" src="_images/CSF-Images-Library.png" style="width: 100%;" /></a>
|
||
</div>
|
||
<p class="topic-title first pt-2 mb-1">C OpenSSL library functions – <openssl/sha.h></p><hr class="mt-1" />
|
||
<p>This is not a standard library, so you may need to use the -I and -L compiler flags.</p>
|
||
<dl class="docutils">
|
||
<dt><code class="docutils literal notranslate"><span class="pre">int</span> <span class="pre">SHA256_Init</span> <span class="pre">(SHA256_CTX</span> <span class="pre">*c);</span></code></dt>
|
||
<dd>Initializes a new context for SHA-256 cryptographic hash calculations.</dd>
|
||
<dt><code class="docutils literal notranslate"><span class="pre">int</span> <span class="pre">SHA256_Update</span> <span class="pre">(SHA256_CTX</span> <span class="pre">*c,</span> <span class="pre">const</span> <span class="pre">void</span> <span class="pre">*data,</span> <span class="pre">size_t</span> <span class="pre">len);</span></code></dt>
|
||
<dd>Updates the internal context for a block of data being hashed.</dd>
|
||
<dt><code class="docutils literal notranslate"><span class="pre">int</span> <span class="pre">SHA256_Final</span> <span class="pre">(unsigned</span> <span class="pre">char</span> <span class="pre">*md,</span> <span class="pre">SHA256_CTX</span> <span class="pre">*c);</span></code></dt>
|
||
<dd>Finalized the hash calculation into a message digest md.</dd>
|
||
<dt><code class="docutils literal notranslate"><span class="pre">unsigned</span> <span class="pre">char</span> <span class="pre">*SHA256</span> <span class="pre">(const</span> <span class="pre">unsigned</span> <span class="pre">char</span> <span class="pre">*d,</span> <span class="pre">size_t</span> <span class="pre">n,</span> <span class="pre">unsigned</span> <span class="pre">char</span> <span class="pre">*md);</span></code></dt>
|
||
<dd>Performs all steps to hash the data in one function call. The last parameter points to a buffer used for temporary storage.</dd>
|
||
</dl>
|
||
</div>
|
||
<p><a class="reference external" href="NetSec.html#cl5-4">Code Listing 5.4</a> demonstrates how to use the OpenSSL functions for SHA-256. In this
|
||
scenario, we are assuming that the data to be hashed has been broken into several fixed-size chunks.
|
||
(If the data resides in a single block of memory, the <code class="docutils literal notranslate"><span class="pre">SHA256()</span></code> function performs the
|
||
initialization, calculation, and finalization of the hash value in a single call.) The context value
|
||
keeps track of the internal state of the hash over repeated calls to <code class="docutils literal notranslate"><span class="pre">SHA256_Update()</span></code>.</p>
|
||
<div class="highlight-c border border-dark rounded-lg bg-light px-0 mb-3 notranslate" id="cl5-5"><table class="highlighttable"><tr><td class="linenos px-0 mx-0"><div class="linenodiv"><pre class="mb-0"> 1
|
||
2
|
||
3
|
||
4
|
||
5
|
||
6
|
||
7
|
||
8
|
||
9
|
||
10
|
||
11
|
||
12
|
||
13</pre></div></td><td class="code"><div class="highlight bg-light"><pre class="mb-0"><span></span><span class="cm">/* Code Listing 5.4:</span>
|
||
<span class="cm"> Compute a single cryptographic hash over a sequence of fixed-size blocks</span>
|
||
<span class="cm"> */</span>
|
||
|
||
<span class="n">SHA256_CTX</span> <span class="n">context</span><span class="p">;</span>
|
||
<span class="n">SHA256_Init</span> <span class="p">(</span><span class="o">&</span><span class="n">context</span><span class="p">);</span>
|
||
<span class="cm">/* Assume we have several blocks that are all the same size;</span>
|
||
<span class="cm"> update the hash value accordingly */</span>
|
||
<span class="k">for</span> <span class="p">(</span><span class="kt">size_t</span> <span class="n">i</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span> <span class="n">i</span> <span class="o"><</span> <span class="n">number_of_blocks</span><span class="p">;</span> <span class="n">i</span><span class="o">++</span><span class="p">)</span>
|
||
<span class="n">SHA256_Update</span> <span class="p">(</span><span class="o">&</span><span class="n">context</span><span class="p">,</span> <span class="o">&</span><span class="n">blocks</span><span class="p">[</span><span class="n">i</span><span class="p">],</span> <span class="n">blocksize</span><span class="p">);</span>
|
||
<span class="cm">/* Write the hash into a byte array */</span>
|
||
<span class="kt">uint8_t</span> <span class="n">hash</span><span class="p">[</span><span class="n">SHA256_DIGEST_LENGTH</span><span class="p">];</span>
|
||
<span class="n">SHA256_Final</span> <span class="p">(</span><span class="n">hash</span><span class="p">,</span> <span class="o">&</span><span class="n">context</span><span class="p">);</span>
|
||
</pre></div>
|
||
</td></tr></table></div>
|
||
</div>
|
||
<div class="section" id="transport-layer-security-tls">
|
||
<h2>5.4.4. Transport-Layer Security (TLS)<a class="headerlink" href="NetSec.html#transport-layer-security-tls" title="Permalink to this headline">¶</a></h2>
|
||
<p>As we have noted previously, neither TCP nor UDP provide any security guarantees. This service is
|
||
provided, instead, by <a class="reference internal" href="Glossary.html#term-transport-layer-security"><span class="xref std std-term">Transport-Layer Security</span></a> (TLS). When an application requires secure
|
||
communication (denoted by attaching an “s” to a protocol name to get HTTPS, SFTP, or IMAPS), TLS is
|
||
the source of that security. TLS is the successor of the secure sockets layer (SSL); due to security
|
||
vulnerabilities, SSL has been prohibited by NIST since 2015 and has been removed from common
|
||
applications such as web browsers. The specification for TLS 1.2 is defined in RFC 5246, while TLS
|
||
1.3 is defined in RFC 8446.</p>
|
||
<p>TLS works collaboratively with TCP to create secure end-to-end communication at the application
|
||
layer. Consider the security needs of such a communication channel. The payload of the TCP segment
|
||
needs both confidentiality and integrity, whereas the header cannot be kept confidential. To be
|
||
precise, if the TCP header is encrypted, the receiving OS could not determine the port number and,
|
||
as a result, the intended recipient process. Consequently, the TCP headers must remain unencrypted,
|
||
but they still need to be protected from tampering.</p>
|
||
<div class="figure mb-2 align-right" id="id15" style="width: 35%">
|
||
<span id="netsectls"></span><a class="reference internal image-reference" href="_images/CSF-Images.5.8.png"><img class="p-3 mb-2 align-center border border-dark rounded-lg" alt="The TCP and TLS handshakes" src="_images/CSF-Images.5.8.png" style="width: 95%;" /></a>
|
||
<p class="caption align-center px-3"><span class="caption-text"> Figure 5.4.8: The TCP and TLS handshakes</span></p>
|
||
</div>
|
||
<p><a href="NetSec.html#netsectls">Figure 5.4.8</a> shows the relationship of TCP and TLS. For example, consider a web
|
||
browser navigating to <code class="docutils literal notranslate"><span class="pre">https://www.example.com</span></code> instead of the standard
|
||
<code class="docutils literal notranslate"><span class="pre">http://www.example.com</span></code>. Recall that one difference between these two is that the HTTP request
|
||
would be delivered to port 80 at the server, whereas HTTPS would go to port 443. In both cases, the
|
||
client initiates a TCP handshake to establish the connection. After the ACK message, with standard
|
||
HTTP, the client would be expected to send an unencrypted HTTP request. With HTTPS, however, the
|
||
client’s next message must be a <code class="docutils literal notranslate"><span class="pre">ClientHello</span></code> that initiates a <a class="reference internal" href="Glossary.html#term-tls-handshake"><span class="xref std std-term">TLS handshake</span></a>. The purpose
|
||
of the TLS handshake is for the two hosts to exchange information to establish a symmetric key for
|
||
encrypting messages to each other. The server replies with a <code class="docutils literal notranslate"><span class="pre">ServerHello</span></code> message, containing the
|
||
server’s <code class="docutils literal notranslate"><span class="pre">Certificate</span></code>, <code class="docutils literal notranslate"><span class="pre">ServerKeyExchange</span></code>, and <code class="docutils literal notranslate"><span class="pre">CertiticateRequest</span></code>. The client responds
|
||
with similar data until both hosts send a <code class="docutils literal notranslate"><span class="pre">Finished</span></code> message to indicate the TLS session has begun.</p>
|
||
<p>The Certificate portion of the TLS handshake messages consists of an X.509 certificate, a data
|
||
structure that contains that host’s public key. The certificate, especially on the server side, is
|
||
typically cryptographically signed by a certificate authority (CA). That is, a CA is a company or
|
||
governmental organization that has used a keyed cryptographic hash function to sign <a class="footnote-reference" href="NetSec.html#f36" id="id10">[4]</a> the digital
|
||
equivalent of the message “This CA confirms Company X has public key 12345.” The public key in the
|
||
Certificate is then used to trade the ServerKeyExchange and ClientKeyExchange messages. These
|
||
messages encode information for a key exchange protocol that allows the two parties to agree on a
|
||
session key. At the end of the TLS handshake, both hosts have agreed on the session key, and they
|
||
use it to encrypt the payloads of the application-layer messages.</p>
|
||
<p>To perform the key exchange, TLS supports three approaches: a pre-shared key (PSK), Diffie-Hellman
|
||
exchange (DHE), or a combination of the two (PSK with DHE). In PSK, the two hosts have been
|
||
configured to use the same key. This approach is used for organizations that are under common system
|
||
administration, but it does not work for two hosts that have no prior contact. Hosts with no prior
|
||
contact use the DHE approach. Without delving into the details, consider the case where the two
|
||
hosts determine a common message. The two hosts could come to an agreement on the key by encrypting
|
||
the same message twice:</p>
|
||
<center>
|
||
<span class="math inline">$\large K = e_A(e_B(m)) = e_B(e_A(m))$</span>
|
||
</center>
|
||
<br /><p>That is, assume Alice has a private key $A$ and Bob’s private key is $B$. Because the order of
|
||
exponents (if this used RSA) does not matter, if Alice encrypts $m$ and Bob encrypts the result,
|
||
that value would be the same as if Bob encrypted $m$ first and Alice encrypted the result. Since no
|
||
one else knows the private keys, Eve cannot compute K even if she knows $m$, $e_A(m)$, and $e_B(m)$.</p>
|
||
<p>To protect the TCP headers, TLS computes a MAC of the original TCP header and attaches the MAC as an
|
||
optional TCP field; the MAC can be computed using a number of hash functions, though SHA-2 is
|
||
perhaps the most common. Attaching the MAC provides an integrity check for both hosts to know that
|
||
no third party has tampered with the segment by replacing the payload contents. TLS 1.2 protected
|
||
the application-layer payload using SHA-2 and AES in the MtE technique shown in <a href="NetSec.html#netsectls">Figure 5.4.8</a>. Because
|
||
MtE is not secure against attacks that reuse the ciphertext (e.g., including an old payload), TLS
|
||
1.3 has removed support for MtE and replaced it with <a class="reference internal" href="Glossary.html#term-authenticated-encryption-with-attached-data"><span class="xref std std-term">authenticated encryption with attached
|
||
data</span></a> (AEAD), a technique that does the MAC and encryption in parallel in a way that avoids the
|
||
ciphertext reuse threat.</p>
|
||
<p>In summary, TLS provides security guarantees that TCP and UDP cannot. By encrypting the
|
||
application-layer payload, its contents are hidden from view while the segment traverses through the
|
||
Internet. Doing so allows applications to send and receive sensitive data, such as passwords or
|
||
credit card numbers; this information is only observed by the processes at the two end hosts. TLS
|
||
also provides assurance that the data has not been tampered with or corrupted without detection.
|
||
Ultimately, the application-layer process has no awareness that these additional calculations are
|
||
being done, as TLS—like TCP—operates within the OS, returning the results to the applications after
|
||
they have already been decrypted and their integrity confirmed.</p>
|
||
</div>
|
||
<div class="section" id="tls-in-practice-https">
|
||
<h2>5.4.5. TLS in Practice: HTTPS<a class="headerlink" href="NetSec.html#tls-in-practice-https" title="Permalink to this headline">¶</a></h2>
|
||
<p>In the previous chapter, we used the <code class="docutils literal notranslate"><span class="pre">netcat</span></code> utility to communicate with an HTTP server. Recall
|
||
that <code class="docutils literal notranslate"><span class="pre">netcat</span></code> takes two command-line arguments: a hostname and a port number. While standard HTTP
|
||
servers listen for incoming requests on port 80, HTTPS uses port 443. Given that HTTPS communicates
|
||
using the same protocol as HTTP—the only difference is that HTTPS runs on top of TLS—it is tempting
|
||
to use the same approach as before, using the different port number:</p>
|
||
<div class="highlight-none border border-dark rounded-lg bg-light px-2 mb-3 notranslate"><div class="highlight bg-light"><pre class="mb-0"><span></span>$ netcat www.example.com 443
|
||
Warning: Inverse name lookup failed for `93.184.216.34'
|
||
www.example.com [93.184.216.34] 443 (https) open
|
||
GET / HTTP/1.0
|
||
read(net): Connection reset by peer
|
||
</pre></div>
|
||
</div>
|
||
<p>What is not immediately obvious in print form is that the last line of this output is produced by
|
||
netcat immediately after the <code class="docutils literal notranslate"><span class="pre">GET</span></code> line is entered. That is, the protocol is aborted immediately
|
||
by the server and the connection is shut down. The reason for this connection loss is that port 443
|
||
is expecting a TLS handshake before any HTTP messages can be processed. Since <code class="docutils literal notranslate"><span class="pre">netcat</span></code> sends all
|
||
messages in an unencrypted format, it cannot be used for TLS sessions. Instead, we can use the
|
||
<code class="docutils literal notranslate"><span class="pre">openssl</span></code> utility (<code class="docutils literal notranslate"><span class="pre">https://www.openssl.org</span></code>) for this purpose. <a class="footnote-reference" href="NetSec.html#f37" id="id11">[5]</a> The <code class="docutils literal notranslate"><span class="pre">openssl</span></code>
|
||
equivalent of the netcat command from above is as follows:</p>
|
||
<div class="highlight-none border border-dark rounded-lg bg-light px-2 mb-3 notranslate"><div class="highlight bg-light"><pre class="mb-0"><span></span>$ openssl s_client -crlf -connect www.example.com:443
|
||
[...almost 100 lines of immediate output...]
|
||
</pre></div>
|
||
</div>
|
||
<p>The first parameter indicates the openssl command to execute, as the same utility can be used to run
|
||
a TLS server, generate cryptographic keys, or many other functions. The <code class="docutils literal notranslate"><span class="pre">-crlf</span></code> option tells
|
||
<code class="docutils literal notranslate"><span class="pre">openssl</span></code> to use both <code class="docutils literal notranslate"><span class="pre">'\r\n'</span></code> when the user hits the enter key, and the <code class="docutils literal notranslate"><span class="pre">-connect</span></code> option is
|
||
used to specific the <code class="docutils literal notranslate"><span class="pre">host:port</span></code> combination. Once the <code class="docutils literal notranslate"><span class="pre">openssl</span></code> command is entered, the utility
|
||
establishes a TCP connection followed by the TLS handshake. This procedure creates almost 100 lines
|
||
of output, including specific information about the server’s certificate and how much data was
|
||
exchanged during the handshake. The last part of this output contains information such as the following lines:</p>
|
||
<div class="highlight-none border border-dark rounded-lg bg-light px-2 mb-3 notranslate"><div class="highlight bg-light"><pre class="mb-0"><span></span>SSL-Session:
|
||
Protocol : TLSv1.2
|
||
Cipher : ECDHE-RSA-AES128-GCM-SHA256
|
||
</pre></div>
|
||
</div>
|
||
<p>These lines indicate that the client and server have agreed to use TLS version 1.2. The key exchange
|
||
protocol is the elliptic-curve version of Diffie-Hellman, using RSA for signatures. The session key
|
||
will encrypt the application-layer payload using a variant of 128-bit AES in Galois/Counter Mode
|
||
(GCM). Any cryptographic hashes will be computed using SHA-256, a 256-bit version of SHA-2.
|
||
Eventually, the handshake messages end and the remainder of the session proceeds as follows:</p>
|
||
<div class="highlight-none border border-dark rounded-lg bg-light px-2 mb-3 notranslate"><div class="highlight bg-light"><pre class="mb-0"><span></span>[...TLS handshake messages before this point...]
|
||
GET / HTTP/1.1
|
||
Host: www.example.com
|
||
Connection: close
|
||
|
||
HTTP/1.1 200 OK
|
||
[...remainder of HTTP response and HTML code...]
|
||
closed
|
||
</pre></div>
|
||
</div>
|
||
<p>As before, we can enter type the HTTP messages in plaintext. In this case, we are using HTTP/1.1,
|
||
which would maintain a persistent connection. When using HTTP/1.1, the last request should include
|
||
the header line <code class="docutils literal notranslate"><span class="pre">Connection:</span> <span class="pre">close</span></code>, which closes the TCP connection after processing the request.
|
||
The HTML ends with the message <code class="docutils literal notranslate"><span class="pre">closed</span></code>, which indicates that the connection has been successfully
|
||
terminated.</p>
|
||
<p>The <code class="docutils literal notranslate"><span class="pre">openssl</span></code> utility encrypts and decrypts all messages without any additional work done by the
|
||
user. This behavior highlights a key strength of layered architectures: Application-layer protocols
|
||
should not have to change to adjust for transport-layer variations. Consequently, applications can
|
||
be written as before. After using <code class="docutils literal notranslate"><span class="pre">connect()</span></code> to create the TCP connection, the application can
|
||
invoke function calls using the OpenSSL library to perform the handshake then proceed as normal. To
|
||
be clear, this procedure is not trivial, as the developer must configure a number of options, load
|
||
valid certificates, and so on. However, once this configuration is done, all messages sent to and
|
||
received from the server will be encrypted.</p>
|
||
<table class="docutils footnote" frame="void" id="f33" rules="none">
|
||
<colgroup><col class="label" /><col /></colgroup>
|
||
<tbody valign="top">
|
||
<tr><td class="label"><a class="fn-backref" href="NetSec.html#id1">[1]</a></td><td>The literature of cryptography commonly uses particular names to denote certain abilities.
|
||
While Alice and Bob are generic benevolent characters, the name Eve (“eavesdropper”) denotes
|
||
someone attempting to learn a secret through passive observation. Similarly, Mallory (“malicious”)
|
||
implies an adversary who strives to cause harm, whether through action or inaction.</td></tr>
|
||
</tbody>
|
||
</table>
|
||
<table class="docutils footnote" frame="void" id="f34" rules="none">
|
||
<colgroup><col class="label" /><col /></colgroup>
|
||
<tbody valign="top">
|
||
<tr><td class="label"><a class="fn-backref" href="NetSec.html#id2">[2]</a></td><td>In practice, no encryption system is perfect. Some have subtle flaws in their algorithms
|
||
that create statistical patterns that can reveal hints. Others have implementation errors that leak
|
||
information by taking longer or producing more heat depending on whether a particular bit of the
|
||
key is a 1 or a 0. Worse still, users of the system might make errors, such as improperly re-using
|
||
a key or plaintext message. During World War II, German operators re-used certain plaintext
|
||
phrases, letting Polish and British cryptographers at Bletchley Park to break messages encrypted
|
||
with Enigma on a daily basis.</td></tr>
|
||
</tbody>
|
||
</table>
|
||
<table class="docutils footnote" frame="void" id="f35" rules="none">
|
||
<colgroup><col class="label" /><col /></colgroup>
|
||
<tbody valign="top">
|
||
<tr><td class="label"><a class="fn-backref" href="NetSec.html#id3">[3]</a></td><td>OpenSSL is available at <code class="docutils literal notranslate"><span class="pre">https://openssl.org</span></code> and can generally be installed through OS
|
||
package managers. Documentation and code samples are available through the Wiki at <code class="docutils literal notranslate"><span class="pre">https://wiki.openssl.org/</span></code>.</td></tr>
|
||
</tbody>
|
||
</table>
|
||
<table class="docutils footnote" frame="void" id="f36" rules="none">
|
||
<colgroup><col class="label" /><col /></colgroup>
|
||
<tbody valign="top">
|
||
<tr><td class="label"><a class="fn-backref" href="NetSec.html#id10">[4]</a></td><td>It may seem circular to use a public key to sign a certificate declaring what someone
|
||
else’s public key is. That is, how do we know the signature on the certificate is valid? Modern web
|
||
browser and similar applications come pre-installed with the public keys for several pre-defined
|
||
trusted CAs that can be used to confirm the signatures of certificates that company or organization
|
||
has signed.</td></tr>
|
||
</tbody>
|
||
</table>
|
||
<table class="docutils footnote" frame="void" id="f37" rules="none">
|
||
<colgroup><col class="label" /><col /></colgroup>
|
||
<tbody valign="top">
|
||
<tr><td class="label"><a class="fn-backref" href="NetSec.html#id11">[5]</a></td><td>Recall that SSL was the predecessor of TLS. OpenSSL was created as an open-source SSL
|
||
library; although SSL has been renamed to TLS, the library retains the OpenSSL name given that this
|
||
name is widely recognized.</td></tr>
|
||
</tbody>
|
||
</table>
|
||
<div
|
||
id="InterNetSecSumm"
|
||
class="embedContainer"
|
||
data-exer-name="InterNetSecSumm"
|
||
data-long-name="Network security questions"
|
||
data-short-name="InterNetSecSumm"
|
||
data-frame-src="../../../Exercises/Internet/InterNetSecSumm.html?selfLoggingEnabled=false&localMode=true&module=NetSec&JXOP-debug=true&JOP-lang=en&JXOP-code=java"
|
||
data-frame-width="950"
|
||
data-frame-height="775"
|
||
data-external="false"
|
||
data-points="1.0"
|
||
data-required="True"
|
||
data-showhide="show"
|
||
data-threshold="5"
|
||
data-type="ka"
|
||
data-exer-id="">
|
||
|
||
<div class="center">
|
||
<div id="InterNetSecSumm_iframe"></div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
|
||
</div>
|
||
|
||
|
||
|
||
<div class="container">
|
||
|
||
<div class="mt-4 container center">
|
||
«  <a id="prevmod1" href="TransLayer.html">5.3. Transport Layer</a>
|
||
  ::  
|
||
<a class="uplink" href="index.html">Contents</a>
|
||
  ::  
|
||
<a id="nextmod1" href="NetLayer.html">5.5. Internet Layer: IP</a>  »
|
||
</div>
|
||
|
||
|
||
</div>
|
||
|
||
<br />
|
||
|
||
<div class="row jmu-dark-purple-bg">
|
||
<div class="col-md-12">
|
||
<center>
|
||
<a id="contact_us" class="btn button-link-no-blue jmu-gold" rel="nofollow" href="mailto:webmaster@opencsf.org" role="button">Contact Us</a>
|
||
<a id="license" class="btn button-link-no-blue jmu-gold" rel="nofollow" href="https://w3.cs.jmu.edu/kirkpams/OpenCSF/lib/license.html" target="_blank">License</a>
|
||
</center>
|
||
</div>
|
||
</div>
|
||
|
||
|
||
|
||
|
||
|
||
|
||
<script src="_static/js/popper.js-1.14.7-min.js" integrity="sha384-UO2eT0CpHqdSJQ6hJty5KVphtPhzWj9WO1clHTMGa3JDZwrnQq4sF86dIHNDz0W1" crossorigin="anonymous"></script>
|
||
<script src="_static/js/bootstrap.min.js" integrity="sha384-JjSmVgyd0p3pXB1rRibZUAYoIIy6OrQ6VrjIEaFf/nJGzIxFDsf4x0xIM+B07jRM" crossorigin="anonymous"></script>
|
||
</body>
|
||
</html> |