COSC 4P14 What else could we discuss? Brock University Brock - - PowerPoint PPT Presentation

COSC 4P14

What else could we discuss?

Brock University

Brock University What else could we discuss? 1 / 28

There’s so much more out there!

No matter how much time we spent here, we could never hope to cover every notable networked technology. However, there’s a small selection of topics that didn’t quite fit into any of the other lectures, that are nevertheless useful to know about, as they can be the lynchpins to broader fields. In particular, let’s discuss things related to integrating the flow of information with meatspace, to spooky information from a distance, and finish up by playing dressup and diving into scary caves. Or, you know, something like that.

Brock University What else could we discuss? 2 / 28

The Internet of Things!

(Does that not sound like something a 3-year old would make up?)

You’ve probably been hearing about the Internet of Things (IoT) quite a bit lately. And, the IoT is... what? Arguably, in a sense, it doesn’t exactly exist. Or, that is, it isn’t a single specific thing Rather, it’s the byproduct of a slowly-growing trend to add internet-connectivity to everything in our lives. Consider some examples that predate the term, but would still have to count: IP cameras for security Weather-forecasting toasters Smart meters for utilities (and, of course, several others)

Brock University What else could we discuss? 3 / 28

The Internet of Things!

So, that means... ?

So then, what is the Internet of Things? There are several possible definitions, but let’s go with: What you get when you use wireless communications, inexpensive sensors, low-power microcontrollers, and often machine learning and batteries, to gather information on, and often make changes to, some environment Of course, there’s obviously great overlap with cloud computing, big data, etc.

Brock University What else could we discuss? 4 / 28

The Internet of Things!

Perhaps an example?

Let’s look at a possible day in a connected world. You wake up, and your coffee is already ready, because you always get up at the same time Mondays It’s sunny today, so the smart glass in your window has frosted You haven’t been downstairs in quite a while, so the climate control has eased off there for efficiency Once you leave the property, your house automatically locks itself While you’re at work, a neighbour’s kid throws a football onto your

• roof. You’re notified and check in to verify all’s good

The home’s empty, so the roomba vacuums; climate control turns off After work, your car takes you out for pizza As you start heading home, your home starts up the heating/cooling

• again. It’s comfortable by the time you arrive

Of course, the lights turn on automatically In the evening, the lights change to warmer tones, to trick your brain into relaxing and helping you get to sleep

Brock University What else could we discuss? 5 / 28

The Internet of Things!

...seriously?

Of course, the totality of that isn’t really common, but there’s nothing on that list any of you couldn’t do. And even then, that’s a very minimal example. Through better collection

• f (and processing on) even more data, you can accomplish some pretty

nifty things. Where’s there currently space for parking in the area? What route should I take to Brock, considering traffic? What’s a good outdoor activity, considering current UV, allergen, and air pollution readings across the region? Can my phone remind me to grab my umbrella before I go to work, based on the weather forecast? Okay, so this is still just scratching the surface. I haven’t even touched on things like inventory-tracking; targeted sales; anything medical; or even voice control over your television, lights, music, etc.

Brock University What else could we discuss? 6 / 28

The Internet of Things!

Practical concerns

Okay, so what do we need? Power

◮ Some devices are fixed installations (e.g. lighting) ◮ Others need batteries, which means either charging or long-life ◮ When on batteries, it’s common to go into a low-power state (sleep)

Computational power

◮ A low-power microcontroller might lack the ability to crunch data, or

control other devices. Often sensors can connect to servers to do the “heavy lifting”

◮ Also consider collecting and assembling data

Getting connectivity to each device that needs it

◮ Do a dozen climate sensors in a home need a dozen IP addresses? Do

you need to access each of those from your phone directly?

◮ Remember personal area networks from earlier in the course: low-power

trivial wireless communications protocols (e.g. Zigbee)

⋆ Consider several devices with short-range chatter, and one IP master Brock University What else could we discuss? 7 / 28

Internet of Things!

So, how can one do it?

Suppose your phone lets your home know to get cozy before you arrive. Option 1: Your thermostat checks in with the smart home server, to see if there are any changes in the needs And then it does again. And then again. And again. And again... Your phone tells the server to get comfy The thermostat finds out on a query, and then needs to keep asking if it’s comfy enough When it’s finally adequately comfy, it resumes asking if there are any

• changes. And again, and...

Keep in mind, if you’re going for RESTful HTTP, each of these also requires the setup and teardown of a TCP session.

Brock University What else could we discuss? 8 / 28

Internet of Things!

That was bad... what’s the alternative?

Option 2, using, say, Message Queue Telemetry Transport (MQTT, a lightweight messaging platform, based on the publish-subscribe model): Establish a TCP connection to server, and leave it open Upon receipt of the phone’s notice, send a short message to the thermostat Maybe also push a notification to phone, to let user know home is comfortizing For each climate reading, send a short message When server receives optimal temperature, tell thermostat to stop Connection stays open until an event triggers further change (Of course, this probably isn’t how you’d really handle climate control; it’s just a hypothetical)

Brock University What else could we discuss? 9 / 28

Internet of Things!

Don’t read too much into that example

Naturally, there are other options, like going to sleep and occasionally waking up, establishing a connection, and checking in. The point was to see some of the design goals: Send as few bytes as possible Save power when possible Only communicate when you actually expect there to be something to say If you wanted to expand the example, say to include multiple climate sensors, not much would change: Most likely, each climate sensor would spend most of its time in rest mode, and occasionally wake up to send new readings to a central smart home server Other devices (e.g. phone) would send requests to said server, which would then make use of the data it’s been receiving If desired, data can be forwarded along to another server for inferring new rules for future climate decisions

Brock University What else could we discuss? 10 / 28

Internet of Things!

Concerns

There are a few things worth noting, before jumping straight into this stuff: Oftentimes, a simple solution is adequate

◮ If your ISP going down means you freeze to death, that’s a bad system

How much data is being collected? Who owns it?

◮ Chances are, you probably won’t roll your own complete smart home,

smart car, mood-lighting, and coffee-making solution, so your data will likely be sent to external servers

◮ One of the biggest concerns of Big Data is that there’s little

transparency in terms of just how much information is being collected

Security relies on plugging holes and controlling points of communication through gateways

◮ The IoT relies on continuously sending unprecedented volumes of

sensitive data through multiple channels, likely to multiple targets

◮ Can ya see where the conflict might arise?

Open vs proprietary standards

◮ Early attempts to build on smart home and smart bulbs were crushed

pretty quickly by manufacturers who disagreed on who “owns” what

Brock University What else could we discuss? 11 / 28

APIs and Authorization

While we’re on the subject of retrieving data from servers, remember that NASA task from your first assignment? Suppose you made an application that used your API key. How hard would it be for someone else to yoink it?

◮ Remember that it was right in the URL

For some services, there’s an easy solution: when generating an API key, you can also dictate additional restrictions on the key, such as allowable IP addresses, referrer URLs, etc. But how would you handle accessing an API on behalf of a user?

Brock University What else could we discuss? 12 / 28

Authentication vs Authorization

You’ve surely seen examples of websites that say things like, Log in with your Google Account!, or Facebook, etc. You might have used services that could retrieve your information, or even perform actions as you. And, clearly, you directly told those sites/services your logins and passwords, right? No? That would be stupid? Then how the heck do they work?!? First, even though this looks like authentication, it’s closer to being authorization

Brock University What else could we discuss? 13 / 28

Authentication vs Authorization

Wait, what? Which is which?

When you log in, you’re authenticating. In the previous example, you’re not logging into the service; you’re actually logging into Google/Facebook/neopets. You’re then (transparently) generating an authorization. Authorization is granting permission to do something In this case, you’re granting them permission to access information about your account And there are lots of other uses for this. Lots of platforms support authorization to let you retrieve or post information, and even integrate that into devices. See, for example, Open Authorization (OAuth).

Brock University What else could we discuss? 14 / 28

Remote access to services

Suppose we want to connect to a remote host. How could one do that? Technically, you could probably find a way to connect a terminal shell through netcat. You’d only get terminal access It’d likely be difficult to get it working Firewall restrictions tend to dislike completely arbitrary connections It would be so grossly insecure that it wouldn’t even be worth trying to reinforce What else could we do?

Brock University What else could we discuss? 15 / 28

Secure SHell

Of course, there’s SSH: Grants both terminal and file access (via scp) Brings in security (confidentiality and authentication) Through a bit of extra work, can provide access to other tools. e.g.:

◮ X11 forwarding ◮ Port-forwarding (effectively creates a proxy) ◮ sshfs ⋆ Creates a local entry in your file system that connects to the remote

resource, allowing most of your traditional applications to access your remote data transparently

However, there are several flaws: it’s difficult to manage multiple simultaneous resource channels, the advanced features are less Windows-friendly, and most of it is extremely unfriendly to mobile platforms.

Brock University What else could we discuss? 16 / 28

Proxies

Hey, what was that word on the previous slide? Proxy? A proxy is a server that you use as an intermediate gateway to some other remote resource. Typically, you at least create a secure connection to the proxy. This is the first/simplest way to avoid local eavesdroppers Proxies used to be popular to avoid surveillance or georestrictions, but as a general tool aren’t inherently very useful (after all, we can already do the same thing via SSH). What we’d like to do is to expand the idea...

Brock University What else could we discuss? 17 / 28

Virtual Private Networks

Suppose you were to create a secure channel to some remote server: You could send all (or much) of your data through that channel, using it as a tunnel Through that secured tunnel, your data goes into a different subnet (on the other side of the server)

◮ You can now behave as though you’re on that subnet, and thus bypass

firewall restrictions

◮ You now have access to hosts and resources on that network

The owner of the local network can’t infer much from your traffic This “VPN” can be transparent to your applications A VPN is more windows-friendly, and vastly more mobile-friendly

Brock University What else could we discuss? 18 / 28

Virtual Private Networks

Benefits

Of course, at least a few benefits should be obvious: It can afford you local privacy

◮ This might also be valuable to the suppliers of remote resources

Can allow multiple offices/campuses to have one shared network Can let providers open up resources to remote users, but still require authentication As with proxies in general, can help avoid georestrictions To compare against using SSH as a proxy: with a VPN, you’ll typically be given an IP on the host network; with an SSH proxy, you appear to everyone else to have the same IP as the SSH server.

Brock University What else could we discuss? 19 / 28

The Ogre Router

Perhaps we could take the idea one step further: Assume our greatest need is for anonymity. e.g. war-torn countries, countries with oppressive governments, etc.

◮ People have been executed for things we take for granted

A VPN represents a single point of failure: if that single service keeps logs of what you’re doing, then it becomes trivial to find out exactly where you’ve been Ideally, what we’d like is to be able to connect to a server, without even that server know where your traffic is going The key is layers.

Brock University What else could we discuss? 20 / 28

The Onion Router

The Onion Router (Tor) is a collection of tools to establish secure circuits, by creating tunnels within tunnels, such that the entry point doesn’t know the destination of traffic coming out of the exit node. The client randomly selects three relay nodes: the entry point, a relay, and the exit node A virtual circuit is established through those three nodes

◮ All traffic intended for another location on the internet is run through

all three of those nodes first

◮ Encryption is set up, such that another layer is unpeeled at each node ◮ From the remote host’s perspective, the traffic is coming from the exit

node

◮ An eavesdropper on any single point of the chain can’t see the whole

path

Periodically, new nodes may be selected, to re-randomize the circuit, but that’s immaterial here

Brock University What else could we discuss? 21 / 28

The Onion Router

Example please?

Let’s walk through an example: Alice wants to talk to Emily, through Bob, Cathy, and Darryl: After selection of nodes and keys are worked out, the virtual circuit is established Alice encrypts a message for Emily thusly:

◮ E(E(E(XE, KD), KC), KB)

Alice sends the encrypted message to Bob Bob decrypts the message: E(E(XE, KD), KC)

◮ He can’t read it, but passes it to Cathy

Cathy decrypts the message: E(XE, KD)

◮ She can’t read it, but passes it to Darryl

Darryl decrypts it, and sends the plaintext (XE) to Emily

◮ Of course, if the original message was encrypted (e.g. HTTPS), then it

isn’t really plaintext; it just isn’t encrypted for onion routing

Brock University What else could we discuss? 22 / 28

Interjection

Before we get any further, do we know the difference bewteen the deep web and the dark web? The deep web is simply the portion of the web that isn’t indexed by search engines. You need to know where to look for resources to find them The dark web is a subset of deep web; not only is it not indexed, it isn’t even accessible through normal web access means The deep web isn’t terribly nefarious: Brock’s library stores tons of research articles and such that are only accessible/visible within Brock Tons of other institutions similarly keep resources that can only be accessed from within their own intranets Anything behind password protection isn’t readily visible to a search engine

Brock University What else could we discuss? 23 / 28

The Onion Router

Dark web services

So, why are we talking about this? The primary purpose of Tor is to allow for anonymous access to the web proper. But what if we never actually left via an exit node? What if we wanted to access other services on Tor? That’s where we get to the dark web (or dark net). The dark net is an example of an overlay network — a spanning network

• f computers, superimposed on the underlying internet. A dark net is an
• verlay network that’s only accessible via speical software (like the Tor

browser). To find dark services, one typically needs to find listings of them, or follow links (as with the web’s early days).

Brock University What else could we discuss? 24 / 28

The Onion Router

Name resolution

But this still raises the question of name resolution — DNS servers

• bviously won’t help you with that!

Sites hosted entirely on Tor use domain names ending with .onion The domains themselves will be 16-character public keys in base32 A service can prove themselves as being the owner by knowing the corresponding private key Though there are exceptions, most of these services aren’t of great academic interest, so moving on...

Brock University What else could we discuss? 25 / 28

The Onion Router

Concerns

Though it can be a valuable tool for certain needs, Tor is far from perfect. Plenty of information can still be inferred, if there’s enough incentive

◮ For example, though someone observing you can’t tell what services

you’re using, they can tell that you’re doing it through Tor

◮ Both VPN and Tor are blocked in Turkey ◮ Services can also tell if you’re coming from a known Tor exit node, and

may assume you’re up to shenanigans and preemptively block you

The easiest way to become compromised is still the human side:

• perations security (OPSEC) failures

◮ Like the Silk Road founder who tied his own gmail address and real

name to his drug empire and bragged about it on LinkedIn

◮ Or the AlphaBay founder who tied his own hotmail address to his drug

empire and LinkedIn profile

◮ Bit of advice: only mention your drug empire on MySpace Brock University What else could we discuss? 26 / 28

Other anonymity layers and dark nets

It’s worth noting that Tor isn’t the only player in the game. For example, there’s also I2P (Invisible Internet Project). Many mechanisms are largely the same Dark web domains end with .i2p Most significant differences relate to difference in design/usage goals:

◮ TOR is an anonymity mechanism, that also happens to have dark web

features

◮ I2P is designed for the dark web, and you might also find an exit node

• r two

There are also other little differences, like the circuit-routing of TOR vs the packet-routing of I2P (that makes things like congestion control and re-routing easier).

Brock University What else could we discuss? 27 / 28

Questions?

Comments?

Otherwise, we’ll have to end a little earlier to do the course evaluations. Which I remembered to bring... right?

Brock University What else could we discuss? 28 / 28