第14章サイバー資源の品質とサイバーコンピューティングのガバナンス

Authentication confirms the identity and authorization of people and devices that use a system. It is a vital two-step process to help ensure that only authorized users have access to a system. Authentication first requires identification followed by verification to establish and confirm a user’s unique credentials and ensure the user is authorized.

A password is a secret string of characters used to gain entry into a system. It is a critical part of authentication. To function as a cybersecurity tool, passwords must be secure, which can be challenging. Attackers can steal passwords by guessing, installing a hardware or software keylogger, finding written passwords, obtaining them via social engineering/phishing, intercepting the password over the network, or stealing them from a service or third party.

To address these cyber threats, the DHS’s Cybersecurity and Infrastructure Security Agency offers three tips for passwords:¹⁵

• Create long passwords with at least 16 characters.

• Make passwords random by following NIST’s recommended password rules.

• Ensure that passwords are unique by using a different password for every access point in a system.

A vital part of cybersecurity is access control, which regulates the people and devices that can use a computer system’s resources. The three most common access control designs include the following:

• Mandatory access control (MAC) is a strict system where security decisions are fully controlled by a central policy administrator, making it impossible for users to set permissions irrespective of ownership.

• Discretionary access control (DAC) is a system where users can set permissions for their files, including granting access rights to other users on the same system. DAC is the most common access control design approach in commercial operating systems. While generally less secure than mandatory control, DAC is easier to implement and more flexible.

• Role-based access control (RBAC) is a system in which access depends on an individual or group’s role in an organization and the access they need to meet job requirements. Typically, roles with more responsibility and authority have greater access to the system.

The typical attacks launched against cryptography generally involve the following:

• brute force (e.g., try all possible private keys)

• mathematical attacks (e.g., factoring)

• timing attacks (e.g., based on knowledge of the time it takes to decrypt)

• hardware-based fault attack (e.g., take advantage of faulty hardware to generate digital signatures)

• chosen ciphertext attack (e.g., gather information by obtaining the decryptions of chosen ciphertexts and attempt to recover from this information the secret key used for decryption)

• architectural changes (e.g., use knowledge of vulnerabilities)

Protecting anonymity and privacy is an important aspect of cybersecurity. Being able to interact on the Internet, even publicly, while concealing your identity, is considered anonymity. Anonymity is not the same as secrecy/confidentiality. As discussed previously, confidentiality is about message contents (i.e., what was said). Anonymity is about identities (i.e., who said it and to whom) and must be preserved to ensure certain civil liberties such as autonomy, free association, free speech, and freedom from censorship and surveillance.

There is a wide spectrum of “nimity,” including

• linkable anonymity (e.g., loyalty cards, prepaid mobile phone),

• (e.g., pen names on blogs),

• unlinkable anonymity (e.g., paying in cash), and

• verinymity (e.g., credit card numbers, driver licenses, addresses).

By remaining anonymous, users make it difficult for hackers to steal their personal data (e.g., passwords, credit card information). It also allows users to preserve their civil liberties (e.g., free speech and association) on social media. Anonymity can also be important for people concerned about their safety and do not want to create safety risks because of their online activities.

Keeping your actions online, such as messages intended only for certain individuals, concealed from the public is called privacy. Privacy is regarded as a basic human right. While not explicit in the U.S. Constitution, privacy rights are implied by the personal protections offered in the First, Third, Fourth, Fifth, and Ninth Amendments in the Bill of Rights. As Figure 14.9 shows, privacy is related to anonymity but is a separate concept. Both anonymity and privacy are important to promote cybersecurity.

15 Cybersecurity & Infrastructure Security Agency. No Date. “Use Strong Passwords.” https://www.cisa.gov/secure-our-world/use-strong-passwords.

Internet anonymity is difficult, if not impossible, to achieve for average users, but it seems easy for unethical people. Anonymity is a state-of-the-art technique that relies on proxy intermediaries that relay Internet traffic through trusted third parties. Generally, the process requires setting up an encrypted virtual private network (VPN) to the third party’s site, and all your traffic goes through it.

To understand how unethical people use proxies, assume a scenario depicted in Figure 14.10 where Alice wants to message M to Bob. Bob does not know that the message M is from Alice, and Eve (“Eve” is short for eavesdropper) cannot determine that Alice is communicating with Bob. HMA accepts messages encrypted for it, then extracts the corresponding destination addresses and forwards the message accordingly.

Anonymity is meant to counter the type of surveillance that is mandated as part of the Patriot Act (section 215, and national security letters or NSLs) and the FISA Amendment Act.

An older Google transparency report (Table 14.4) shows the number of NSLs that FBI agents issued without a judge’s approval to obtain personal information.

NSLs cover everything except the contents of your communications (i.e., if, when, how much, who). These data are included in the exception because such metadata often provides privileged information that is essentially, according to the FTC, a “proxy for content.” In fact, the U.S. National Security Agency (NSA) collection of bulk call data was ruled illegal in 2015.

Encryption tools such as Pretty Good Privacy (PGP), which was introduced earlier, can be used. GnuPG is a free software recreation of PGP created by Phil Zimmerman (1991). These tools allow users to encrypt emails to hide their content by creating a hash of the email’s content and using digital signatures to sign the hash. Both the message text and the digital signature attached to the message are protected using hybrid encryption. Digital signatures require public-key cryptography (which has separate public and private keys). Before sending a message, the message is signed with the signature key, and both the message and its signature are encrypted with the recipient’s public encryption key. Once the message is received, it is decrypted with the private key to extract it and its signature. The sender’s public verification key is then used to check the signature’s authenticity.

Fingerprints must be used to secure this process further. Because Bob’s public key can be obtained from his website, it needs to be verified via out-of-band communication of fingerprints. A fingerprint is a cryptographic hash of a key. To support this approach, you need key servers that store public keys to look up keys by name/ email address and verify them with fingerprints. If you do not know Bob personally, you can rely on the Web of Trust (WoT) or “friend of a friend” mechanism (i.e., Bob introduces Alice to Caro by signing Alice’s key).

There are drawbacks to (just) using encryption because Bob’s private key may be compromised. In that case, the specifics of the keys may become known, and past messages may be decrypted and read. Because the sender’s signature is available as part of the messages sent, it also becomes possible to prove the sender’s identity, which defeats the security scheme. This attack exposes many incriminating records, including the key material that decrypts data sent over the public Internet and signatures with proofs of who said what.

There is nothing better than “off-the-record” conversations where Alice and Bob talk in a room, and no one else can hear them. In that case, no one else knows what they say unless Alice or Bob tells them. Furthermore, no one can prove what was said, not Alice or Bob. Based on this, desirable communication properties are as follows:

• Deniability makes it plausible to deny having sent a message.

• Forward secrecy allows past messages to be safe even if key material if compromised.

• Mimic off-the-record conversations to facilitate deniable authentication. Make it possible to be confident of who you are talking to but unable to prove to a third party what was said.

One technique is to use off-the-record (OTR) messaging.

1. Use authenticated Diffie-Hellman (DH) protocol to establish a (short-lived) session key: Diffie-Hellman is a security algorithm with only one (symmetric) private key that is shared by both participants (e.g., Alice and Bob). Alice and Bob agree on values for prime number p and a generator number g (or base), where 1< g < p and g is any number agreed upon by both parties that is a generator of p. The number g is a generator of p because, when raised to positive whole-number powers less than p, it never produces the same result for any two such whole numbers. For ease of computation, g is usually chosen small, and the order of g should be prime and approximately p/2. Alice and Bob pick private values x and y respectively and they generate a key and exchange it publicly. So Alice selects x and generates public key a = gx modulo p and Bob selects y and generates public key b = gy modulo p. For example, if p = 23 and g = 9, the private keys for Alice and Bob are respectively 4 and 3, and the secret keys for Alice and Bob are both 9. During the DH key (signed) exchange, the only pieces of information that are exposed to the public (and susceptible to interception by malicious actors) are x, y, p, and g. None of which are sufficient to recover Alice and Bob’s private keys. It is also not enough information to recover the shared (symmetric) secret (SS) cryptographic key. SS can then be used by Alice and Bob to send encrypted messages to each other safely, which is done using a secret-key encryption algorithm, using a hash of SS as the encryption key EK, to transmit ciphertext. The strength of the scheme comes from the fact that (gy)x modulo p = (gx)y modulo p is a one-way function that takes an extremely long time to compute/invert using any known algorithm (just from the knowledge of p, g, gx modulo p, and gy modulo p.

(attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

2. Then Alice uses secret-key encryption on message M and sends it across as EEK(M) ... and authenticates the message using a message authentication code MACMK(EEK(M), where MK is computed as a hash of the EK, H(EK):

(attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

3. Re-keying is performed using the DH protocol to exchange new private values x′ and y′:

(attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

4. Publishing the old MK:

(attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Note that OTR is more applicable to interactive communication than email. It provides message authentication, confidentiality, deniability, and forward secrecy. However, there are no practical examples of “deniability.” OTR is built into Adium and Pidgin; in that case, some defaults apply. In particular, logging is enabled by default, and etiquette dictates you should disable this, as do past instances where people’s activities were discovered using those logs (e.g., Chelsea Manning, who leaked classified information, was discovered after the Army reviewed access logs). It is very different from Google Hangout’s OTR feature, which does not allow the conversation to be logged.

An interesting anonymity solution is the protocol behind the Signal app (iPhone, Android), which uses the double ratchet algorithm set forth by Trevor Perrin and Moxie Marlinspike. It provides forward secrecy (i.e., today’s messages are secret, even if the key is compromised tomorrow), future secrecy (i.e., tomorrow’s messages are secret, even if the key is compromised today), deniability (no permanent/transferable evidence of what was said), and usability (i.e., tolerates out-of-order message delivery).

Another interesting idea for anonymity is achieved via plausibly deniable storage. In this case, the goal is to encrypt data stored on your hard drive. Someone can be compelled to decrypt it. The idea is to have a “decoy” volume with benign information (e.g., VeraCrypt).

Note that it may be worthwhile to differentiate sender from receiver anonymity. An interesting example of a protocol that achieves sender anonymity is described by David Chaum as the “dining cryptographers problem.”¹⁶ In this case, three cryptographers dining together are told that payment will be made anonymously by either one of them or the agency that employs them. As they respect each other’s right to make an anonymous payment but wonder if their agency will be paying, they carry out the protocol described to achieve sender anonymity.

16 Chaum, David. “The Dining Cryptographers Problem: Unconditional Sender and Recipient Untraceability. Journal of Cryptology, vol. 1, 65–75, 1998. https://chaum.com/wp-content/uploads/2022/01/chaum-dc.pdf

Tor end-to-end paths are called Circuits, and Tor almost always uses 3-hop circuits (i.e., k = 3). Tor balances anonymity (i.e., k not too small so as to be traceable) and latency (i.e., k not too large). The last node in a Tor circuit is called an "exit” node. To the outside world, the Tor exit node is initiating connections to destinations. Every peer in the Tor network gets to decide whether to be an exit node or to just relay between other Tor nodes. Tor exit nodes also determine what IP addresses/websites to exit. Tor clients learn about other Tor peers by downloading a list of them.¹⁷ The list provides information for each one of the Tor routers, such as IP address and hostname, the country where it resides, the uptime, the average throughput, websites it is willing to be an exit node for, and the node’s public key.

Tor’s attack model is more “relaxed” than the models used by typical mix-nets. In particular, Tor does not assume a global, passive attacker. It does assume that a limited subset of the Tor nodes are malicious and that there may be some level of eavesdropping on small portions of the links but not a global view of all traffic. This relaxed attack model, which assumes a less powerful adversary, makes it possible for Tor to achieve better performance. That said, there are a few aspects that Tor does not cover as compared to typical mix-nets: Tor does not batch or delay packets. If only one client were to communicate over Tor, there would be no anonymity. The philosophy behind the Tor relaxed attack model is to assume that if the performance is reasonable enough, users will be more likely to adopt it. The more users adopt it, the more "cover traffic" there will be, making it harder for an attacker to map packets to any one sender. Figure 14.12 summarizes how Tor works at a high level.

17 A list of active Tor peers (i.e., Tor routers) is available at https://torstatus.rueckgr.at.

Tor implements the following trust protocol:

• Entry node knows that Alice is using Tor, and also knows the identity of the middle node but does not know the identity of the destination.

• Exit node knows that some Tor user is connecting to the destination but does not know which user.

• Destination knows a Tor user is connecting to it via the exit node.

It should be noted that Tor does not provide encryption (e.g., use HTTPS) between the exit node and the destination). We discussed earlier how senders can hide their identities. Similar to that, Tor is also a means of allowing destinations to hide their identities. An example was The Silk Road, an eBay-like online store where users could purchase illicit and illegal goods and pay for them using Bitcoins. Running such a website requires a certain degree of anonymity. Therefore it was run as what is known as a "Tor hidden service." Hidden services have since been renamed to onion services.¹⁸ Interestingly, onion services can achieve receiver anonymity using techniques that achieve sender anonymity (Figure 14.13).¹⁹

18 To read more about how onion services work, visit https://community.torproject.org/onion-services/overview/, and to read more about how to set them up, visit https://community.torproject.org/onion-services/setup/. 19 For more information on Tor, how it is used, and where it is being censored, check out the Tor metrics site at https://metrics.torproject.org/.

Note that there are various known onion routing attacks and other issues as follows:

• Attacks:

◦ Rubber-hose cryptanalysis of mix operators; as a defense, use mix servers in different countries

◦ Adversary operates all of the mixes; as a defense, has lots of mix servers.

◦ Adversary observes when Alice sends and when Bob receives and links the two together.

◦ Side channel attack exploits timing information; as a defense, pad messages or introduce significant delays. (Tor does the former, but note that it is not enough for defense.)

• Issues include

◦ impaired performance (i.e., messages may bounce around a lot) and

◦ traffic leakage (suppose all of your HTTP/HTTPS traffic goes through Tor, but the rest of your traffic does not).

Concerning the traffic leakage problem, Tor’s solution is to inspect the logs of their DNS server to see who looked up sensitive.com just before your connection to their web server arrived. The hard, general problem is that anonymity is often at risk when an adversary can correlate separate sources of information.

To summarize, Tor hides metadata (i.e., the “what,” or message content) via TLS/PGP/OTR/Signal, and also hides the “who” via the onion routing protocol. It also provides a messaging system called Pond (Figure 14.14), which hides the “when” and “how much” parts as illustrated. Note that Pond is not an email; rather, it is a forward, secure, asynchronous messaging system. Pond seeks to protect the possibility of leaking traffic info against all but a global passive adversary (i.e., forward secure, no spam allowed, and messages expire automatically after a week).