Get Connected to Windows 10 IoT Core on Your Raspberry Pi

USB Ports

Connect to Windows 10 #IoT Core on Your Raspberry Pi with Secure Shell, the Web and Visual Studio.

In my last article, I showed you how to get Windows 10 IoT Core installed on your Raspberry Pi 2. In order to remotely configure, monitor and push Universal Windows Platform apps to your Pi, your Windows 10 PC must be able to connect. A critical element in making all this work is to ensure your PC is on the same network and subnet as the Raspberry Pi 2. Lets get to work.

A quick glance at your Raspberry Pi’s home screen will show you its name and IP address.

Windows Home

From the command prompt of your Windows 10 PC, run ipconfig to verify that it is on the same network and subnet. Sending a ping to your Raspberry Pi to ensure you can reach it is a good idea as well. If your connectivity is good, then it’s time to remotely connect via Secure Shell (SSH) so you can run commands on your Raspberry Pi.

In order to connect with Secure Shell, you’ll need need a remote shell client for Windows. PuTTY is a commonly used, open source terminal emulator that can be downloaded here. Once it’s downloaded, launch the app, type in the IP address of your Raspberry Pi, select the SSH radio button and click the Open button.

PuTTy

The first time you connect, you may experience a slight delay and a Security Alert dialog below might popup. Just click the Yes button to proceed.

Security Alert

Once you connect, type the default value of Administrator at the login as: screen and hit enter. Next, type the default password of p@ssw0rd and hit enter.

SSH Login

Welcome back to DOS! No Edlin jokes…

SSH

Let’s try a few commands. If you don’t like the default device name of minwinpc, you can change it by typing setcomputername <new name>. I changed mine to houseofpi in honor of the Houston restaurant where Rod Canion and the other founders of Compaq hatched their plan for a new computer company on a paper placemat. Type hostname to make sure you got it right.

One thing I absolutely want you to change is the Administrator password since your new IoT device is currently in a vulnerable state.  Type net user Administrator <new password>to make this happen. Please take IoT security seriously so you don’t contribute to creating the largest attack surface in the history of computing. A good list of Windows 10 IoT Core command line utilities can be found here.

Now lets move on to see how you can connect to your Raspberry Pi via the web.

Looking back to the installation of Windows 10 IoT Core for Raspberry Pi 2 from the previous article, it installed an app called Windows IoT Core Watcher which can be found from the Windows Start menu at All apps | Microsoft IoT. When you launch this app, it should display your Raspberry Pi in a list as shown below:

Windows IoT Core Watcher

Right-click on your device and select Web Browser Here from the context menu. Since you just changed your password, the browser will prompt you for it before displaying the page. As you can see below, the Home page just shows you some minimal information about your Raspberry Pi.

WebHome

The App page shows you a dropdown list of installed apps that you can run, uninstall or set as the default app at the top. Remember, only one app can run in the foreground at a time on Windows IoT Core. The Install app section is interesting in that it lets you remotely install your app (.appx), associated certificate (.cer) and any other dependencies your app may have.

AppX

The Process page works similarly to the Task Manager on your PC and displays a list of running processes along with associated CPU and memory usage. Clicking the X next to any of the processes will kill it.

Processes

Also like the Task Manager on your PC, the Performance page displays real-time CPU and file I/O utilization and memory usage.

Performance

There are a lot of other pages to explore that deliver helpful information and diagnostics to help you be successful with Windows 10 IoT Core on the Raspberry Pi 2. Definitely check them out.

As you might imagine, the whole point of having Windows 10 IoT Core is to run apps. This is where Visual Studio 2015 and the Universal Windows Platform comes in.

RTM versions of Visual Studio 2015 Community, Professional or Enterprise are required to get started. Make sure Universal Windows App Development Tools -> Tools and Windows SDK are installed during the setup procedure. After installation, download the Windows IoT Core Project Templates from the Visual Studio Gallery to make your File | New Project experience more productive. Last but not least, make sure developer mode is enabled by following these instructions.

If the Raspberry Pi devices you’re targeting are deployed with a connected monitor that a person can interact with, create a Windows Universal Blank App project in Visual Studio to deliver a user interface. On the other hand, if you’re targeting headless Raspberry Pi devices, create a Windows IoT Core Background Application in Visual Studio.

Once your headless or GUI IoT app project is loaded, you’ll have to make some adjustments to Visual Studio in order to deploy and debug against your Raspberry Pi. You’ll need to select ARM to support the Broadcom CPU and Remote Machine to debug over Ethernet.

ARM x86 Remote

It’s possible that a Remote Connections dialog will popup when you select Remote Machine for the first time. If Visual Studio cannot find your Raspberry Pi automatically, type in its IP address in the Address text box. Select none instead of Windows for Authentication Mode and click the Select button.

Remote Connections

Next, I want you to go to the Solution Explorer and double-click on the Properties icon of your IoT project. Click Debug on the left side of the screen and ensure that Target device is set to Remote Machine and the IP address of your Raspberry Pi is displayed in the Remote machine text box. Click the Find button to verify that Visual Studio can connect. If your Pi cannot be found, it’s possible that Visual Studio’s remote debugger on the Pi has shut down after a long time of inactivity. Try restarting your Raspberry Pi and give it another shot.

Debug

If all goes well, the Remote Connections dialog should popup and the name of your Pi should be displayed beneath the Auto Detected section. Click the Select button.

Remote Connections Success

After the dialog closes, make sure that the Use authentication check box is unchecked and then click the Save icon. At this point, you should be able to hit F5 and remotely debug against your Raspberry Pi.

As you can see, there’s no shortage of ways to connect, configure, control and debug against your Raspberry Pi running Windows 10 IoT Core. Now start building those IoT apps using the development tools and programming languages you’re comfortable with.

Getting Started with Azure IoT services: Securing Event Hub Telemetry with SAS Tokens

Azure Security

To prevent the Internet of Things from becoming the largest attack surface in the history of computing, security at scale is paramount. #IoT

Any company that wants to be taken seriously as an IoT platform player has to provide cloud-scale telemetry ingestion while also delivering security to millions of events per second without skipping a beat. This is no easy task and therefore narrows down the field in this space dramatically. Microsoft Azure IoT services accomplishes this task through the use of Shared Access Signatures (SAS). They provide delegated, limited access to resources such as Event Hubs for a specified period of time with a specified set of permissions. Of course it does this without having to share the account access keys you created in the previous Event Hub article. You might remember creating a Shared Access Policy with Send permissions. You gave that policy a name and were given a connection string that includes the account access key which you used to test out a .NET IoT client. Good for testing. Career-limiting for production. That’s why you’re reading this article.

In regards to securely sending telemetry to Event Hubs, IoT devices and field gateways claim access to the Event Hub by presenting a SAS token. This token consists of the resource URI being accessed, and an expiry signed with the account access key. Basically, a URL-encoded string that is passed along every time telemetry is sent. Each IoT device needs its own distinct SAS token and that’s what you’re going to learn today.

To more easily create SAS tokens for your IoT clients, I want you to create a simple app to do the work for you. Launch Visual Studio and create a new C#, Windows Forms application and call it SASToken. From the Solution Explorer, right-click on References and select Manage NuGet Packages…

In the Search Online box type Azure Service Bus and install version 2.7.5 or later. Since you’ll be using the SharedAccessSignatureTokenProvider class to create a shared access signature for your publisher, add using Microsoft.ServiceBus; above the namespace with all the other using statements in the default Form class.

The next thing I want you to do is create a function called CreateSASToken() inside the Form class as shown below:

Create SAS Token

This function simplifies the creation of a SAS token by inputting values found on the Azure portal for your Event Hub. Let’s walk through the parameters of this function and where you can find the required values:

  • EventHubUri: This is found on the Dashboard page of your Event Hub under Event Hub URL. Don’t include the last part of the URL after the final dash /
  • EventHubName: This is found at the top of your Event Hub Dashboard page.
  • Publisher: This is a unique name you get to create for the IoT device that’s sending the telemetry to the Event Hub.
  • PolicyName: This is found on the Configure page of your Event Hub and is the name of the shared access policy you created with Send permissions.
  • PolicyKey: At the bottom of your Event Hub’s Configure page is a section called shared access key generator. Select the correct Policy Name from the dropdown box and copy the Primary Key in the text box below it.
  • Expiration: Enter the number of minutes you want your token to be valid. This TimeSpan code can be changed so you can use days or hours as well.

With the function up and running, you can now create unique tokens for each of your Publishers rather than insecurely using the same connection string for all of them. This also means that your Event Hub can prevent individual Publishers from sending telemetry if any of them have been compromised. To make better use of this function, follow along and build a simple data entry form.

Load the default Form in the Visual Studio and add the following UI controls and associated properties:

  • Label: Text = Event Hub Uri:
  • TextBox: Name = txtEventHubUri
  • Label: Text = Event Hub Name:
  • TextBox: Name = txtEventHubName
  • Label: Text = Publisher:
  • TextBox: Name = txtPublisher
  • Label: Text = Policy Name:
  • TextBox: Name = txtPolicyName
  • Label: Text = Policy Key:
  • TextBox: Name = txtPolicyKey
  • Button: Name = btnCreateSAS  Text = Create SAS Token
  • Label: Text = SAS Token:
  • TextBox: Name = txtSASToken

In order to bring things to life, create a click event for the Button and add the following code:

Create SAS Code

The code calls the CreateSASToken() function you created and passes in the values you type or paste into the TextBoxes. I hard-coded in 60 minutes but you can make that any number you like and you could even add a NumericUpDown control. The function returns a SAS token as a string and displays it in the TextBox at the bottom of the Form.

At this point, go ahead and run the app you just built. Type in or paste the appropriate values from the Azure portal into the TextBoxes. I called my Publisher 007 but you can call it anything you want. Click the button and you should get a SAS token as shown below:

SAS Form

While you now have an easy way to create SAS tokens, this won’t suffice at large scale. You’ll need to use what you’ve learned here to build a secure, on-premises or cloud-based token service to support deployment to thousands or even millions of individual IoT devices.

With your unique SAS token in hand, it’s time to modify the the app you created in the previous Event Hub article. Load the ContosoIoTConsole solution in Visual Studio and get ready to make a few changes.

Just like you did with the SAS token app, add using Microsoft.ServiceBus; above the namespace with all the other using statements in the Program class. Next, delete the first two lines of code inside Main() where you previously created a connectionString and an EventHubClient. In place of the deleted code you’ll declare a string called sasToken and paste in the long SAS token string that was generated by the Windows app you just built. Next, you’ll declare a connectionString and use the ServiceBusConnectionStringBuilder along with your Service Bus URI, Event Hub name, Publisher name, and SAS token to create it instead of reading the account access key from App.config like the previous article. In the final, new line of code, you’ll create an EventHubSender based on this new connection string. Every other line of code below stays the same. Your updated ContosoIoTConsole app should look like the code below with your Event Hub values substituted for mine:

Event Hub Sender Code

All that’s left to do is try it out by running the console app and then checking your Event Hub Dashboard a few minutes later to see if a new message arrived.

By following the directions and code in this article, you’ve made the leap to getting an IoT client to send telemetry to Event Hubs more securely. While Event Hubs has always required transport via TLS, by presenting a SAS token, Event Hubs knows who the IoT client is and what permissions it has. A SAS token’s ability to gain access to Event Hubs doesn’t last forever due to the expiration limitations you place on it when creating a new token which is a good thing. Furthermore, Event Hubs give you device blacklisting capabilities by revoking individual publishers based on the unique name you gave them. Expired tokens and revoked publishers will result in errors being thrown in the client code when a publisher attempts to send telemetry to an Event Hub. Keep in mind that when you do a mass deployment, your IoT clients and field gateways won’t have this information hard-coded like the example we just walked through. It must be encrypted and will often be baked into the hardware silicon as the IoT devices are being manufactured. Stay secure!