├── tech-theory-time ├── virtual-machines │ ├── encryption01.png │ ├── index.html │ └── vm-presentation.md └── information-assurance │ ├── arrow.svg │ ├── key.svg │ ├── scroll.svg │ ├── index.html │ ├── scroll3.svg │ └── presentation.md ├── README.md ├── lib └── base.css ├── index.html ├── CONTRIBUTING.md └── LICENSE.md /tech-theory-time/virtual-machines/encryption01.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/18F/acq-tech-presentations/master/tech-theory-time/virtual-machines/encryption01.png -------------------------------------------------------------------------------- /tech-theory-time/information-assurance/arrow.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 10 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # acq-tech-presentations 2 | 3 | A collection of tech-related AcqStack presentations. 4 | 5 | ## Public domain 6 | 7 | This project is in the worldwide [public domain](LICENSE.md). As stated in [CONTRIBUTING](CONTRIBUTING.md): 8 | 9 | > This project is in the public domain within the United States, and copyright and related rights in the 10 | > work worldwide are waived through the 11 | > [CC0 1.0 Universal public domain dedication](https://creativecommons.org/publicdomain/zero/1.0/). 12 | > 13 | > All contributions to this project will be released under the CC0 dedication. By submitting a pull 14 | > request, you are agreeing to comply with this waiver of copyright interest. 15 | -------------------------------------------------------------------------------- /lib/base.css: -------------------------------------------------------------------------------- 1 | @import url(https://fonts.googleapis.com/css?family=Arimo); 2 | @import url(https://fonts.googleapis.com/css?family=Droid+Serif:400,700,400italic); 3 | @import url(https://fonts.googleapis.com/css?family=Ubuntu+Mono:400,700,400italic); 4 | 5 | body { 6 | font-family: 'HelveticaNeue','Droid Serif'; 7 | background-color: rgb(21,35,58); 8 | color: white; 9 | font-size: 16pt; 10 | } 11 | h1, h2, h3 { 12 | font-family: 'HelveticaNeue','Arimo'; 13 | font-weight: bold; 14 | color: rgb(12,197,255); 15 | } 16 | .remark-code, .remark-inline-code { font-family: 'Ubuntu Mono'; } 17 | .remark-slide-content { 18 | background: rgb(21, 35, 58); 19 | font-size: 28px; 20 | } 21 | 22 | .highlight { 23 | color: rgb(235, 255, 32); 24 | } 25 | 26 | .loud { 27 | color: rgb(12, 197, 255); 28 | } 29 | 30 | .white { 31 | color: white; 32 | } 33 | -------------------------------------------------------------------------------- /index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | AcqStack Tech Presentations 5 | 6 | 7 | 26 | 27 | 28 |

AcqStack Tech Presentations

29 |

Tech-Theory Time

30 |

Information assurance
Virtual machines

34 | 35 | 36 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | ## Welcome! 2 | 3 | We're so glad you're thinking about contributing to an 18F open source project! If you're unsure about anything, just ask -- or submit the issue or pull request anyway. The worst that can happen is you'll be politely asked to change something. We love all friendly contributions. 4 | 5 | We want to ensure a welcoming environment for all of our projects. Our staff follow the [18F Code of Conduct](https://github.com/18F/code-of-conduct/blob/master/code-of-conduct.md) and all contributors should do the same. 6 | 7 | We encourage you to read this project's CONTRIBUTING policy (you are here), its [LICENSE](LICENSE.md), and its [README](README.md). 8 | 9 | If you have any questions or want to read more, check out the [18F Open Source Policy GitHub repository]( https://github.com/18f/open-source-policy), or just [shoot us an email](mailto:18f@gsa.gov). 10 | 11 | ## Public domain 12 | 13 | This project is in the public domain within the United States, and 14 | copyright and related rights in the work worldwide are waived through 15 | the [CC0 1.0 Universal public domain dedication](https://creativecommons.org/publicdomain/zero/1.0/). 16 | 17 | All contributions to this project will be released under the CC0 18 | dedication. By submitting a pull request, you are agreeing to comply 19 | with this waiver of copyright interest. 20 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | As a work of the United States Government, this project is in the 2 | public domain within the United States. 3 | 4 | Additionally, we waive copyright and related rights in the work 5 | worldwide through the CC0 1.0 Universal public domain dedication. 6 | 7 | ## CC0 1.0 Universal Summary 8 | 9 | This is a human-readable summary of the [Legal Code (read the full text)](https://creativecommons.org/publicdomain/zero/1.0/legalcode). 10 | 11 | ### No Copyright 12 | 13 | The person who associated a work with this deed has dedicated the work to 14 | the public domain by waiving all of his or her rights to the work worldwide 15 | under copyright law, including all related and neighboring rights, to the 16 | extent allowed by law. 17 | 18 | You can copy, modify, distribute and perform the work, even for commercial 19 | purposes, all without asking permission. 20 | 21 | ### Other Information 22 | 23 | In no way are the patent or trademark rights of any person affected by CC0, 24 | nor are the rights that other persons may have in the work or in how the 25 | work is used, such as publicity or privacy rights. 26 | 27 | Unless expressly stated otherwise, the person who associated a work with 28 | this deed makes no warranties about the work, and disclaims liability for 29 | all uses of the work, to the fullest extent permitted by applicable law. 30 | When using or citing the work, you should not imply endorsement by the 31 | author or the affirmer. 32 | -------------------------------------------------------------------------------- /tech-theory-time/virtual-machines/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Virtual machines | AcqStack mini-tech time 5 | 6 | 7 | 58 | 59 | 60 | 61 | 63 | 66 | 67 | 68 | -------------------------------------------------------------------------------- /tech-theory-time/information-assurance/key.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 19 | -------------------------------------------------------------------------------- /tech-theory-time/information-assurance/scroll.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /tech-theory-time/information-assurance/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Information Assurance | AcqStack mini-tech time 5 | 6 | 7 | 192 | 193 | 194 | 195 | 197 | 200 | 201 | 202 | -------------------------------------------------------------------------------- /tech-theory-time/information-assurance/scroll3.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 105 | -------------------------------------------------------------------------------- /tech-theory-time/virtual-machines/vm-presentation.md: -------------------------------------------------------------------------------- 1 | class: left, top 2 | # Virtual machines (VM) 3 | little computers inside your computer 4 | 5 | --- 6 | 7 | ### What's a real computer? 8 | 9 | * hardware - motherboard, processor, RAM, storage, video, USB 10 | * operating system (OS) - lowest user-level software; Windows, MacOS, Linux 11 | * applications - Slack, Chrome, Atom 12 | 13 | --- 14 | 15 | ### What's a real computer? 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 |

Slack	Chrome	Atom	apps...
operating system (Windows, macOS, Linux)
hardware (processor, memory)

31 | 32 | --- 33 | 34 | ### Virtual machines 35 | 36 | # .white[A virtual machine is logically an entire computer] 37 | 38 | It just runs on .highlight[virtual] hardware 39 | 40 | --- 41 | 42 | ### Virtual machines / .white[virtual hardware] 43 | 44 | > “Not physically existing but made by software to appear to do so” 45 | 46 | ??? 47 | 48 | If you look up the word "virtual" in the dictionary, there's a standalone definition 49 | for the word as it applies to computing. This is it. It's not super helpful. The 50 | standard definition is "almost as described, but not completely by definition." 51 | 52 | -- 53 | count: false 54 | 55 | Software applications can manage the way other applications can use the hardware. 56 | As far as the second application can tell, it's using the hardware directly, but 57 | in fact, the first application is managing how it uses the hardware. The first 58 | application has created .highlight[virtual hardware]. 59 | 60 | ??? 61 | The second application think it's looking at actual hardware. It's... almost as 62 | described. In fact, the second application is looking at another application that 63 | is mediating its view of the hardware. 64 | 65 | -- 66 | count: false 67 | 68 | The applications that create virtual hardware for virtual machines are called 69 | .highlight[hypervisors]. It's a weird word. 70 | 71 | -- 72 | count: false 73 | 74 | The *how* is really complicated. We won't go there. 75 | 76 | --- 77 | 78 | ### Virtual machines 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 |

app	app	app	⬅ vm
guest operating system
virtual hardware
hypervisor			apps...
host operating system
hardware

104 | 105 | --- 106 | 107 | ### Virtual machines 108 | 109 | A virtual machine runs on virtual hardware, created and managed by the .highlight[host] 110 | machine. That means the host controls the .highlight[guest's] access. 111 | 112 | * how much memory it can access 113 | * how much processor time it can use 114 | * which files it can see 115 | * etc. 116 | 117 | When a "real" computer is also running virtual machines, we refer to the 118 | "real" computer as the .loud[host]. The virtual machines are called 119 | .loud[guests]. 120 | 121 | --- 122 | 123 | ### Virtual machines 124 | 125 | The .highlight[hypervisor] essentially pokes a hole through the host OS directly to the hardware 126 | and lets the guest machine access the hardware through that controlled mechanism. 127 | 128 | The guest is .highlight[isolated] from the host. The guest can't access 129 | memory or storage that hasn't been specifically set aside for it. The guest can't 130 | see the host's network activity. 131 | 132 | The host can still see everything, but in practice hosts generally don't peak into 133 | guests except to figure out problems. 134 | 135 | ??? 136 | 137 | Isolation is a huge deal here. It means that the guest can't compromise the host. That's 138 | a security benefit, but it's also an operational benefit - if the VM crashes, it doesn't 139 | take the host down with it. You're basically creating little isolated boxes of risk. 140 | 141 | --- 142 | 143 | ### Virtual machines / .white[the cloud] 144 | 145 | ## .white[Most of the computers in the cloud are virtual machines] 146 | 147 | Using virtual machines, cloud providers can turn a fixed amount of hardware into a 148 | variable number of computers. They can add computers as needed without necessarily 149 | having to add hardware. 150 | 151 | And they can let the hypervisors automate a lot of the creation process. It's not unusual 152 | to be able to create a new virtual machine in less than a minute. 153 | 154 | cloud.gov is on virtual machines in an Amazon data center 155 | 156 | --- 157 | 158 | ### Containers 159 | 160 | There are other kinds of virtualization, like containers (these are what 161 | .highlight[Docker] creates). Containers are *not* entire virtual computers. 162 | 163 | Containers use what is called "operating system virtualization" instead of 164 | hardware virtualization like virtual machines use. 165 | 166 | ## The host shares its operating system into the container 167 | 168 | --- 169 | 170 | ### Containers 171 | 172 | 173 | 174 | 175 | 176 | 177 | 178 | 179 | 180 | 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | 189 | 190 | 191 | 192 |

app	app	app	⬅ container
container image
container manager			apps...
host operating system
hardware

193 | 194 | The .highlight[container image] keeps track of any changes the container makes to the 195 | operating system, but it _only_ stores the changes. Those changes are only visible to 196 | the container and don't affect the host! 197 | 198 | --- 199 | 200 | ### Containers / .white[advantages over VMs] 201 | 202 | * because they use the host's operating system, they turn on instantly - no boot-up 203 | * they also don't need as much storage or memory because they use the host's operating system 204 | * they don't need much configuration - they inherit it from the host operating system 205 | * generally they only run a single application 206 | * more isolation - applications are isolated from each other rather than just machines 207 | 208 | --- 209 | 210 | ### Containers / .white[the cloud] 211 | 212 | ## .white[More and more of the applications in the cloud are in containers] 213 | 214 | Using containers, cloud providers can put ***even more stuff*** on the same amount of hardware. 215 | It also increases security and reliability because the containers are isolated from each other - 216 | one can't steal data from its neighbor, and if it crashes, it crashes alone 217 | 218 | cloud.gov apps live in containers 219 | 220 | --- 221 | class: middle center 222 | # .white[Questions?] 223 | 224 | --- 225 | -------------------------------------------------------------------------------- /tech-theory-time/information-assurance/presentation.md: -------------------------------------------------------------------------------- 1 | class: left, top 2 | # Information Assurance 3 | the formal and more complicated name for computer security 4 | 5 | ### .right[what even is it?] 6 | 7 | --- 8 | 9 | ### Keeping secrets secret 10 | 11 | Information assurance is about making sure people can only see the information 12 | they're supposed to see, and ensuring that the information is what it claims 13 | to be. 14 | 15 | * Confidentiality 16 | * Integrity 17 | * Availability 18 | 19 | ??? 20 | 21 | This is the traditional information assurance triad. 22 | 23 | --- 24 | 25 | ### Keeping secrets secret 26 | 27 | Information assurance is about making sure people can only see the information 28 | they're supposed to see, and ensuring that the information is what it claims 29 | to be. 30 | 31 | * Confidentiality 32 | * Integrity 33 | * ~~Availability~~ .highlight[Authentication and Authorization] 34 | 35 | Availability isn't ***strictly*** concerned with the security of information 36 | but it is a critical part of .highlight[information assurance]. For our purposes, 37 | availability can generally be considered .highlight[someone else's problem]. 38 | 39 | ??? 40 | 41 | But for this talk, we're going to shift our focus a little bit. Auth/auth 42 | technically fall under confidentiality, but it's a complex topic and is more 43 | relevant to us. 44 | 45 | The "someone else" we leave to "availability" here is 46 | operations staff, like the IT folks responsible for making sure the servers 47 | stay up or that a denial-of-service attack is being dealt with. It's a hard 48 | job, but also not one that we will have to address very often. 49 | 50 | --- 51 | 52 | ### The balancing act 53 | 54 | One of the first lessons of information assurance is that we must balance 55 | security with the ability to do work (i.e., security vs. convenience). 56 | 57 | -- 58 | 59 | ## The "lock it all down" mentality is in direct opposition to one of the fundamental tenets of information assurance. 60 | 61 | ??? 62 | 63 | There's also a recognition that "perfect" security is impossible. Instead, 64 | we strive for "good enough," which takes into account the sensitivity of 65 | the information and how much effort someone is realistically likely to put into 66 | getting it. The goal is to make it hard enough that an adversary won't bother, 67 | or that if they do, it will take long enough that it's no longer relevant. 68 | 69 | --- 70 | 71 | class: section, middle, center 72 | # Confidentiality 73 | making sure the neighbor reading your mail doesn't learn anything useful 74 | 75 | --- 76 | 77 | ### Confidentiality 78 | 79 | 1. Ensures that only the parties involved in a communication can see the 80 | information in it 81 | 2. Ensures that outsiders cannot learn information based on the _shape_ 82 | of the data 83 | 3. Does ***not*** ensure that the information is what you think it is, 84 | nor that you're talking to who you think you're talking to. 85 | 86 | .highlight[Data] is a stream of stuff going past you. It doesn't necessarily 87 | have any meaning. .highlight[Information] is the meaningful stuff you get 88 | from data when you understand its context. 89 | 90 | ??? 91 | Data is just a bunch of zeroes and ones in a file. If you don't understand 92 | the structure of the data, then it's meaningless to you. But if someone 93 | says, "Hey, that's an Excel file," now it has meaning. You open it up and 94 | view the information the data conveys. 95 | 96 | This distinction comes from information theory. 97 | 98 | --- 99 | 100 | ### Confidentiality 101 | 102 | # .white[Physical space] 103 | .loud[Confidentiality in meatspace] 104 | 105 | --- 106 | 107 | ### Confidentiality / .white[Physical space] 108 | 109 | In the physical world, confidentiality is easy to understand (though sometimes 110 | hard to implement): 111 | 112 | * Face-to-face conversation 113 | * Handing a note directly to the person you want to read it 114 | * Having meetings in a sound-proof room 115 | * That SCIF-life 116 | 117 | --- 118 | 119 | ### Confidentiality 120 | 121 | # .white[Cryptography] 122 | .loud[Confidentiality in the digital world] 123 | 124 | --- 125 | 126 | ### Confidentiality / .white[Crypto] 127 | 128 | Cryptography is the study of secure information transmission. It includes 129 | encryption, decryption, secure hashing, secure random number generation, 130 | and more. 131 | 132 | It assumes that other people already have access to your communications 133 | channel and attempts to make it impossible for them to read your 134 | information even though they can see your data. 135 | 136 | --- 137 | 138 | ### Confidentiality / .white[Crypto >] .highlight[Encryption] 139 | 140 | Encryption is mixing up some information so people can't read it 141 | without knowing how it was mixed up. It consists of four parts: 142 | .highlight[plaintext], .highlight[cipher], .highlight[key], and 143 | .highlight[ciphertext]. 144 | 145 | .crypto-splainer[ 146 | .plaintext-scroll[![](scroll3.svg)] 147 | .scroll-text[.plaintext-scroll-text[This is a super secret message only Alice should see]] 148 | .label-plaintext[plaintext] 149 | .key[![](key.svg)] 150 | .label-key[key] 151 | .cipher-block[cipher] 152 | .ciphertext-scroll[![](scroll3.svg)] 153 | .arrow-p2c[![](arrow.svg)] 154 | .arrow-k2c[![](arrow.svg)] 155 | .arrow-c2c[![](arrow.svg)] 156 | .scroll-text[.ciphertext-scroll-text[ae661d08d1c a6efcb82b7b 19a31bf4f11 6c5de2f489f]] 157 | .label-ciphertext[ciphertext] 158 | ] 159 | 160 | --- 161 | 162 | ### Confidentiality / .white[Crypto >] .highlight[Encryption] 163 | 164 | You've probably done encryption! 165 | 166 | 167 | 168 | 169 | 170 | 171 | 172 | 173 | 174 | 175 | 176 | 177 | 178 | 179 | 180 | 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | 189 | 190 | 191 | 192 | 193 | 194 | 195 | 196 | 197 | 198 | 199 | 200 | 201 | 202 | 203 | 204 | 205 | 206 | 207 | 208 | 209 | 210 | 211 | 212 | 213 | 214 | 215 | 216 | 217 | 218 | 219 | 220 | 221 | 222 | 223 |

224 | 225 | .loud[a] becomes .highlight[t], .loud[b] becomes .highlight[u], 226 | .loud[c] becomes .highlight[v], and so on... 227 | 228 | -- 229 | 230 | This represents a cipher called .highlight[Caesar Shift] (or sometimes 231 | .highlight[Caesar cipher]) with a key of .highlight[7]. The key is 232 | the secret that tells you how the cipher was applied. In this case, it shifts the 233 | letters by 7. 234 | 235 | --- 236 | 237 | ### Confidentiality / .white[Crypto >] .highlight[Encryption] 238 | 239 | .crypto-splainer[ 240 | .plaintext-scroll[![](scroll3.svg)] 241 | .scroll-text[.plaintext-scroll-text[This is a super secret message only Alice should see]] 242 | .label-plaintext[plaintext] 243 | .key[![](key.svg)] 244 | .key-text[7] 245 | .label-key[key] 246 | .cipher-block[Caesar shift] 247 | .ciphertext-scroll[![](scroll3.svg)] 248 | .arrow-p2c[![](arrow.svg)] 249 | .arrow-k2c[![](arrow.svg)] 250 | .arrow-c2c[![](arrow.svg)] 251 | .scroll-text[.ciphertext-scroll-text[Mabl bl t lnixk lxvkxm fxlltzx hger Tebvx lahnew lxx]] 252 | .label-ciphertext[ciphertext] 253 | ] 254 | 255 | If you give someone the ciphertext and they know the key, they can decrypt 256 | the plaintext. Ideally, only people with the key can read the message. 257 | 258 | ??? 259 | This is really weak encryption. The shape of the ciphertext gives us a lot 260 | of information we can use to figure out the plaintext. Look at the third word: 261 | it's a single-letter word. How many of those are there? Just two. So T must 262 | either be A or I. Now if we can figure out one more letter, we will know the 263 | key and we can decrypt the message. 264 | 265 | --- 266 | 267 | ### Confidentiality / .white[Crypto >] .highlight[It's hard!] 268 | 269 | * Don't want to accidentally reveal anything 270 | * "shape" of the ciphertext (frequency of letters, number of words, length of 271 | information, etc.) can tell you about the plaintext 272 | * the cipher that was used makes it easier to attack the ciphertext 273 | (.highlight[life pro tip:] .loud[don't treat the cipher as a secret]) 274 | * Don't want to create weaknesses in the cipher 275 | * bad random number generation 276 | * mathematical oddities 277 | * "magic" numbers (i.e., back doors) 278 | 279 | ??? 280 | 281 | E is the most common letter in English writing, T is the second most, etc. 282 | Think of *Wheel of Fortune*: R, S, T, L, N, and E are all near the top of 283 | the list of letters when ranked by how common they are in English text. 284 | 285 | Only the key should be considered a secret. In some cases, it's possible to 286 | figure out what cipher was used based on the ciphertext and that is 287 | considered completely okay. 288 | 289 | ### NSA magic number 290 | 291 | NSA may have picked parameters for an algorithm that are highly correlated 292 | mathematically, in a way that is difficult to prove. If so, they created a 293 | backdoor in that algorithm. 294 | 295 | --- 296 | class: center, middle 297 | 298 | .huge[SO DON'T EVER MAKE YOUR OWN] 299 | 300 | --- 301 | 302 | ### Confidentiality / .white[Crypto >] .highlight[It's hard!] 303 | 304 | Always use well-known, well-established cryptographic ciphers, particularly those 305 | vetted by NIST. These ciphers have been carefully developed and researched 306 | by dedicated cryptographers and mathematicians to root out as many hidden 307 | mistakes as possible. 308 | 309 | * Advanced Encryption Standard (AES) 310 | * RSA 311 | * Twofish 312 | 313 | --- 314 | 315 | ### Confidentiality / .white[Crypto >] .highlight[It's hard!] 316 | 317 | Sometimes the well-known ciphers are later shown to have vulnerabilities. Here 318 | are a few fairly common ciphers that are no longer considered safe and should 319 | generally be avoided: 320 | 321 | * Data Encryption Standard (DES) 322 | * Triple DES 323 | * despite the name, it's only really about twice as strong as DES 324 | * Rivest Cipher 4 (RC4) 325 | 326 | On the internet, web servers that support these ciphers in SSL are considered 327 | to be at risk. 328 | 329 | ??? 330 | 331 | ### DES 332 | 333 | The granddaddy of widespread ciphers, and the granddaddy of insecure ones. Developed 334 | in the 1970s, blessed by FIPS in 1977. That blessing led to fast adoption, 335 | but also lots of attention. By the mid-80s, there were lots of theoretical ways to 336 | break it, but in the late 90s, it was officially and practically broken. 337 | 338 | ### 3DES 339 | 340 | The biggest problem with DES was the short, 56-bit key. 3DES was designed to allow 341 | a longer key without redesigning the entire algorithm - they would have three 56-bit 342 | keys instead of just one, or effectively 168 bits. But there were some quirks that 343 | resulted in only two of the keys being effective, so it was limited to 112 bits at 344 | best. But due to some other mistakes, NIST currently says it's effectively only 80 bits. 345 | 346 | 3DES is still considered secure enough by NIST, but the broader internet community 347 | encourages moving away from it - it will probably be broken soon. 348 | 349 | ### RC4 350 | 351 | It was created in 1987 and was super fast, leading to widespread adoption, 352 | including in SSL (HTTPS). But it was banned from SSL in 2015 - it was suspected 353 | that state actors had the ability to break arbitrary RC4. 354 | 355 | --- 356 | 357 | class: section, middle, center 358 | # Integrity 359 | making sure your neighbor didn't change your letters 360 | 361 | --- 362 | 363 | ### Integrity 364 | 365 | In information assurance, integrity is *just* about making sure the information 366 | you receive is the same information that was sent. That is, nobody in the 367 | middle changed anything. 368 | 369 | --- 370 | 371 | ### Integrity 372 | 373 | # .white[Physical space] 374 | .loud[Integrity in meatspace] 375 | 376 | --- 377 | 378 | ### Integrity / .white[Physical space] 379 | 380 | In the physical world, integrity can be tricky: 381 | 382 | * Check that the handwriting matches the sender's 383 | * like on those credit card signature slips that nobody ever looks at 384 | * Check that your mail wasn't opened 385 | * like back in the old days when letters were sealed with wax seals 386 | * Send them a text and ask if they really wrote that letter 387 | * Send them an email asking if they got your text 388 | * don't do that 389 | 390 | --- 391 | 392 | ### Integrity 393 | # .white[Cryptography] 394 | .loud[Integrity in the digital world] 395 | 396 | --- 397 | 398 | ### Integrity / .white[Crypto] 399 | 400 | Yep, cryptography again. But this time, we don't rely on encryption. Instead, 401 | we rely on one-way algorithms that transform some data into some other data 402 | in such a way that it cannot be transformed back. 403 | 404 | ...That really sounds useless, doesn't it? 405 | 406 | --- 407 | 408 | ### Integrity / .white[Crypto] 409 | 410 | These algorithms are called cryptographic hash functions. When you put some data 411 | in, the result is called a hash (sometimes they're called digests or fingerprints). 412 | 413 | `hash("Hello world") => 3e25960a79dbc69b674cd4ec67a72c62` 414 | 415 | .highlight[(real example!)] 416 | 417 | ??? 418 | 419 | This is using a hash algorithm called MD5. 420 | 421 | --- 422 | 423 | ### Integrity / .white[Crypto >] .highlight[Hash properties] 424 | 425 | 1. **One-way** 426 | It should be impossible to go from a hash back to the original data 427 | 428 | 2. **Unique** 429 | Different data should *always* produce different hashes 430 | 431 | 3. **Repeatable** 432 | The same data should *always* produce the same hash 433 | 434 | 4. **Easy to make** 435 | Making a hash is mathematically easy 436 | 437 | --- 438 | 439 | ### Integrity / .white[Crypto >] .highlight[Use of a hash] 440 | 441 | * Alice writes a letter to Bob and then computes the hash for the letter 442 | * Alice puts the letter in the mail, and texts the hash to Bob 443 | * When Bob gets the letter, he also computes the hash 444 | * If Bob's hash matches the one he got from Alice, it's the same letter! 445 | Otherwise, it has been tampered with. 446 | 447 | This is called "fingerprinting" - using a hash to ensure the information you 448 | received is the same information that was sent 449 | 450 | ??? 451 | 452 | out-of-band 453 | 454 | This is a contrived example, you wouldn't actually do this by hand. 455 | But if you have digital signatures turned on in your email, for example, 456 | it does this for you behind the scenes. It's a little more complicated 457 | than our example, but this is the gist of it. 458 | 459 | downloads 460 | 461 | --- 462 | 463 | class: section, middle, center 464 | # Authentication 465 | who even *is* your neighbor? 466 | 467 | --- 468 | 469 | ### Authentication 470 | 471 | Authentication is about verifying the truth or validity of something. 472 | In computer world, we are most often talking about verifying a 473 | person's identity. 474 | 475 | --- 476 | 477 | ### Authentication 478 | 479 | # .white[Physical space] 480 | .loud[Authentication in meatspace] 481 | 482 | --- 483 | 484 | ### Authentication / .white[Physical space] 485 | 486 | 1. **Driver's license** 487 | > It has a photograph, name, and security features that we can check 488 | to verify that the holder is who they say they are 489 | 490 | 2. **Iris scan** 491 | > Iris patterns are believed to be completely unique. If your iris 492 | matches the one on file, you must be that person 493 | 494 | 3. **Speakeasy** 495 | > Walt sent me 496 | 497 | --- 498 | 499 | ### Authentication 500 | 501 | # .white[Passwords and more!] 502 | .loud[Authentication in the digital world] 503 | 504 | --- 505 | 506 | ### Authentication / .white[Shared secret] 507 | 508 | If you know a secret and you tell me, then I can verify your identity 509 | by asking you to tell me that secret again. 510 | 511 | The canonical example is a .highlight[password]. Combined with your 512 | .highlight[username], I can know who you are... 513 | 514 | .loud[...as long as nobody else knows your password...] 515 | 516 | --- 517 | 518 | ### Authentication / .white[Two-factor] 519 | 520 | Something you know, something you have, something you are. Pick two. 521 | 522 | * **you know...** passwords 523 | * **you have...** your cell phone 524 | * **you are...** a fingerprint 525 | 526 | ??? 527 | 528 | know - financial services; addresses, car, loans, etc. 529 | 530 | --- 531 | 532 | class: section, middle, center 533 | # Authorization 534 | preventing your neighbor from reading your mail in the first place 535 | 536 | --- 537 | 538 | ### Authorization 539 | 540 | Authorization is about making sure people can only see and do the things 541 | they're supposed to be able to see and do. This requires being able to 542 | .highlight[authenticate] people. 543 | 544 | --- 545 | 546 | ### Authorization 547 | 548 | # .white[Physical space] 549 | .loud[Authorization in meatspace] 550 | 551 | --- 552 | 553 | ### Authorization / .white[Physical space] 554 | 555 | 1. **Walls** 556 | > Limits the options of people trying to enter a building to just openings 557 | like doors and windows 558 | 559 | 2. **Guards** 560 | > Security guards prevent people from entering a place unless they're authorized 561 | 562 | 3. **Lock & key** 563 | > Locks keep people from accessing things unless they have the key 564 | 565 | --- 566 | 567 | ### Authorization 568 | 569 | # .white[Access Controls] 570 | .loud[Authorization in the digital world] 571 | 572 | --- 573 | 574 | ### Authorization / .white[Access control >] .highlight[Walls] 575 | 576 | Like in physical space, we can have "digital walls" that prevent access to digital 577 | resources. Mostly these are .highlight[firewalls], devices that sit on the network 578 | and deny access to internal assets from outside. 579 | 580 | ??? 581 | 582 | We can use a VPN to make a private connection to the internal network from outside. 583 | That way, we can access stuff that the firewall is protecting. 584 | 585 | --- 586 | 587 | ### Authorization / .white[Access control >] .highlight[Guards] 588 | 589 | We also have "guards" that only allow authorized access 590 | 591 | * Access control lists say who can log into computers 592 | * Permission required to access someone else's files on Google Drive 593 | * Your phone only unlocks for ***your*** thumbprint, not all of them 594 | 595 | These guards are all software that has to be carefully checked to verify that it 596 | is checking the user's credentials and only allowing the access they're supposed 597 | to have. 598 | 599 | --- 600 | 601 | ### Authorization / .white[Access control >] .highlight[Guards] 602 | 603 | Guards can check for a lot of things 604 | 605 | * Do you have access to this website? 606 | * Do you have permission to edit blog posts? 607 | * Do you have permission to merge a pull request? 608 | 609 | These are called .highlight[permissions]. 610 | 611 | --- 612 | 613 | class: section 614 | ### Authentication and authorization 615 | 616 | They are similar, and they generally go hand-in-hand. Once we authenticate a person, 617 | we then authorize them to see and do things. 618 | 619 | * When you arrive at the airport, you show your driver's license to security. 620 | They scan it with the little blacklight. They are .highlight[authenticating] 621 | your driver's license and validating that you are who claim to be. 622 | * When you board the aircraft, you scan your boarding pass. The boarding agent 623 | is .highlight[authorizing] you to take a seat on that particular flight but 624 | not any of the other ones. 625 | 626 | --- 627 | 628 | class: middle center 629 | # .white[Questions?] 630 | 631 | --- 632 | 633 | ### Some fun extra reading 634 | 635 | * [All about letter frequency analysis](https://en.wikipedia.org/wiki/Letter_frequency) 636 | * [NSA magic number backdoor](https://arstechnica.com/security/2014/01/how-the-nsa-may-have-put-a-backdoor-in-rsas-cryptography-a-technical-primer/) 637 | * [A (dated) history of DES](http://www.umsl.edu/~siegelj/information_theory/projects/des.netau.net/des%20history.html) 638 | --------------------------------------------------------------------------------