With the increasing adoption of IoT devices, security is a top priority for device manufacturers and consumers alike. Recently, we received questions about the implementation of our S0 and S2 security frameworks. Specifically, when connecting an S2-enabled device, such as a door lock, to a Z-Wave controller implemented with S0 security, the connection between the two devices will be based on S0.

Reverting from S2 to S0 does not put the homeowner at risk. This is a known behavior due to backwards compatibility and S0 was evaluated extensively in 2013. According to an analysis by Z-Wave and SensePost, a trusted cybersecurity consulting firm, while it’s possible that an attacker could intercept the S0 encrypted key exchange frame and decipher it using the hardcoded key, this is only possible during the initial set-up or reinstallation of the device. To do this, the attacker would need to be within close proximity of the device during the very moment the device is installed - an extremely small window of opportunity. Furthermore, Z-Wave devices can switch their radio to low power transmission mode during key exchange process to make packet interception attack much more difficult.

While we know this about S0 device pairing, there have been no known real-world exploits to report.

Z-Wave hired the best security experts to help improve the S0 framework, and the result is S2. S2 is the best-in-class standard for security in the smart home today, with no known vulnerabilities, and mandatory for all new Z-Wave products certified since April 2017.

More than a hundred devices have adopted S2, and the Z-Wave Alliance is working with manufacturers to further deploy the best-in-class S2 standard for security in the smart home. 

The S2 framework was developed together with the cybersecurity expert community to provide new levels of impenetrability. By securing communication both on the local home network as well as in the cloud, Z-Wave smart home end-devices and gateways, S2 also virtually removes the risk of devices having a short instance of vulnerability while being included in the network. Common IoT hacks such as man in the middle and brute force are virtually powerless against the S2 framework through the implementation of the industry-wide accepted secure out-of-band inclusion and key exchange using Elliptic Curve Diffie-Hellman (ECDH). In fact, we’ve offered a $50k bounty to anyone able to exploit a vulnerability using an S2 development kit.

Z-Wave S2 benefits include:

Protection against

• Hacks and man-in-the-middle-attacks
• Inclusion of rogue nodes
• Deciphering of keys
• Sniff & replay and delay attacks

Support for

• Out-of-band inclusion
• Elliptic Curve Diffie-Hellman key exchange
• Strong AES 128 encryption
• Unique/nonce transmissions
• Jamming detection
• LAN Security with DTLS
• IP tunneling security with TLS

Additional Resources:

• Independent analysis of the Z-Wave S2 Security framework
• Z-Wave Alliance statement on S2 mandate for devices 
• Video overview of the S2 framework
• SensePost Security Evaluation of the Z-Wave S0 and S2

 

Introduction

In this post, The Case of the Cycle-to-Cycle Jitter Rule of Thumb, I will review a rule of thumb that can be used for estimating the RMS cycle-to-cycle jitter if all you have available is the RMS period jitter. The reason I’m doing so this month is that a couple of colleagues of mine recently asked me to reconcile a particular Timing Knowledge Base article versus one of our app notes . I first observed this rule of thumb in the lab and subsequently learned more about it.

 

What’s the Rule of Thumb?

It’s real simple. If the period jitter distribution is Gaussian or normal, then the cycle-to-cycle jitter can be estimated from the period jitter as follows:

Jcc (RMS) = sqrt(3) * Jper (RMS)

I first recorded this in a Timing Knowledge Base article Estimating RMS Cycle to Cycle Jitter from RMS Period Jitter. I wrote at the time the following statement:

The sqrt(3) factor arises from the definitions of period jitter and cycle-to-cycle jitter in terms of the timing jitter of each clock edge versus a reference clock.

I will spend a little bit more time on this thought today and attack the problem from several different angles.

 

What’s the Question?

In our application note, A Primer On Jitter, Jitter Measurement and Phase-Locked Loops, the figure below shows the following slopes for post-processing phase noise into timing jitter metrics. Period jitter and cycle-to-cycle jitter are shown as high pass filters with 20 dBc/dec and 40dB/dec slopes, respectively. This is correct and a useful illustration to keep in mind.

The question is how can RMS cycle-to-cycle jitter be larger than RMS period jitter, per the sqrt(3) rule, and the cycle-to-cycle jitter filter have a steeper slope? The answer is that it’s not just the slope that determines the end result. More on that later.

 

Some Terminology

Before proceeding, here are a couple of definitions adapted from AN279: Estimating Period Jitter from Phase Noise.

• Cycle-to-cycle jitter - The short-term variation in clock period between adjacent clock cycles. This jitter measure, abbreviated here as JCC, may be specified as either an RMS or peak-to-peak quantity.
• Period jitter - The short-term variation in clock period over all measured clock cycles, compared to the average clock period. This jitter measure, abbreviated here as JPER, may be specified as either an RMS or peak-to-peak quantity.

The distinction between these time domain jitter measurements is important, hence the italicized terms above. (By the way, you can find old examples in the academic and trade literature where these terms may mean different things, so always double-check the context). The terms here are as used presently and in standards such as JEDEC Standard No. 65B, “Definition of Skew Specifications for Standard Logic Devices”.

 

Example Lab Measurement

First, the following example lab measurement comes straight from the KB article. The annotated image has been made more compact for convenience.

There are three items called out on the screen capture.

1. The period distribution after 1 million cycles appears Gaussian and comes very close to meeting the 68-95-99.7 % rule for ±1, ±2, and ± 3 standard deviations respectively.
2. The measured RMS period jitter is the standard deviation of the period jitter distribution or about 1.17 ps.  We can therefore estimate the RMS cycle to cycle jitter as sqrt(3) * 1.17 ps or 2.03 ps.
3. The actual measured cycle to cycle jitter is 2.05 ps which is reasonably close to the estimate.

 

Example Excel Demonstration

You can also demonstrate this rule in Excel simulations. Exploring the effect, I generated a spreadsheet where I took an ideal clock edge and then jittered the edges by taking random samples from a Gaussian distribution. I then took the period measurements, and the cycle to cycle measurements, over five trials each for 30 edges, and 100 edges with the clock edges representing a jittery 100 MHz clock. Note that since the cycle-to-cycle jitter results are signed, i.e. positive or negative, we should expect the standard deviation of these quantities to be larger, all else being equal. The 100 edges trials were usually much closer to the sqrt(3) rule than the 30 edges trials but you could still see the general effect even over just 30 edges.

If you are interested in playing with it, the spreadsheet is attached as CCJ_ROT_Demonstrator.xlsx. 

 

An Explanation

So how does this rule of thumb arise? As mentioned previously, I first observed this in the lab years ago and learned I could count on it. Yet, I have seen little written about this. Eventually I ran across Statek Technical Note 35, An overview of oscillator jitter. The explanation below is a somewhat simplified and modified version of that derivation where the quantities are expected values for a “large” time series (recall my comments about 100 edges converging to the rule better than 30 edges.)

Let the variable below represent the variance of a single edge’s timing jitter, i.e. the difference in time of a jittery edge versus an ideal edge.

 

Every period measured then is the difference between 2 successive edge values, where each edge jitter has variance s2j. Period jitter is sometimes referred to as the first difference of the timing jitter. Since cycle-to-cycle jitter is the difference between adjacent periods it can be referred to as the second difference of the timing jitter.

If each edge’s jitter is independent then the variance of the period jitter can be written as

 

 

 

 

This is just what we would expect per the Variance Sum Law. You can see an example here, which states that for independent (uncorrelated) variables:

 

 

However, we can’t calculate cycle-cycle jitter quite as easily since in every cycle-to-cycle measurement we use one “interior” clock edge twice and therefore we must account for this. Instead we write:

 

 

 

Since each edge’s jitter is assumed to be independent and have the same statistical properties we can drop the cross correlation terms and write:

           

            

 

The ratio of the variances is therefore

 

 

 

This is an interesting and unexpected result, at least to me :)  

 

Post-Processing Phase Noise

AN279: Estimating Period Jitter from Phase Noise describes how one can estimate period jitter from phase noise based on applying a 4[sin(pi*f*tau)]^2 weighting factor to the phase noise integration. The weighting factor is predominately a +20 dB/dec high pass filter until reaching a peak at the half-carrier frequency.

It turns out that you can use a similar approach to calculating cycle-to-cycle jitter. This requires applying a {4[sin(pi*f*tau)]^2}^2 or 16[sin(pi*f*tau)]^4 weighting factor which is predominately a +40 dB/dec high pass filter until reaching a peak at the half-carrier frequency.  This is exactly what AN687 refers to.

So how can a sharper HPF skirt integrate such that cycle-to-cycle jitter is larger than the period jitter and the sqrt(3) rule applies?

I had to dig up my old Matlab program which I used when writing that app note. Fortunately, I still had the file and the original data. I then ran a modified version of the program and compared the results for max fOFFSET where the phase noise dataset is extended and truncated at both fc/2 and fc. The answer is that while the cycle-to-cycle HPF skirt is steeper the maximum is also higher. See the plots below. The blue wide trace is the period jitter weighted (filtered) phase noise and the red wide trace is the cycle-to-cycle jitter weighted phase noise.  It’s the larger far offset phase noise contributions that make the difference.

 

The original data was for a 160 MHz CMOS oscillator which had a scope measured period jitter at the time of about 2 ps. To be conservative, it was for that reason that I often ran the integration further out than fc/2. Scopes are lower noise now and it would be interesting to go find the original device under test and measure it on a better instrument. My main interest here is to see if the sqrt(3) relationship holds true. As you can see, the rule of thumb holds up in both cases.

Well I hope you have enjoyed this Timing 101 article. The sqrt (3) rule of thumb for cycle-to-cycle jitter holds up well in the lab, in Excel spreadsheet simulations, and when post-processing phase noise.

As always, if you have topic suggestions, or there are questions you would like answered, appropriate for this blog, please send them to kevin.smith@silabs.com with the words Timing 101 in the subject line.  I will give them consideration and see if I can fit them in. Thanks for reading. Keep calm and clock on.

Cheers,

Kevin

 

 

Did you know you can sign up for our monthly newsletter tailored specifically for Silicon Labs community members? Here are top five reasons why you should subscribe:

Stay Informed on Hot Topics

First, you will get informed of the most popular forum discussions among peer engineers. We feature the most interesting topics within IoT, Internet Infrastructure, and Industrial Automation on a monthly basis.

Get the Latest Resources

Second, you can access the latest training resources about Silicon Labs products. You will receive information about the latest video tutorial, webinar, or knowledge base article once a month in your inbox.

Be Inspired

Third, you will be surprised to see how many inspiring projects and real-life applications were built by our members and customers. We introduce those cool examples featuring Silicon Labs’ part to you through our community newsletter.

Learn about the Newest Products

Fourth, you will stay on top of our latest hardware and software releases as well as new product launches.

Stay Connected

Fifth, the community is the place to share your knowledge and connect with each other. Through our featured member section in the newsletter, you will get to know our distinguished community members better.

 

 

The Silicon Labs Dynamic Multiprotocol allows you to support multiple wireless protocols on a single chip.

This technology time-slices the radio and rapidly changes configurations to enable different wireless protocols to operate reliably at the same time. 

The technology leverages Micrium OS Kernel to run each wireless stack as a separate RTOS task.

You are probably aware of the multiple benefits of SystemView; a tool to record and analyze the Micrium OS Kernel events in real-time.

To enable SystemView, Simplicity Studio offers this utility that inserts the required C files and configures the project include paths all by the press of a button. It sounds great, except that it is usually broken by constant changes in the different SDKs from Silicon Labs.

In this blog, I'm gonna describe how to add SystemView to your DMP project manually, for those situations in which fancy tools just won't work.

 

Inserting the SystemView Recorder Files to your DMP Project

Right-click over the project name to open the context menu and select the options New -> Folder

Click the button Advanced >>  select the option Link to alternate location (Linked Folder) and enter the following path:

STUDIO_SDK_LOC\util\third_party\segger\systemview

 

As shown in the image below:

 

 

Inserting the Include Paths in your Compiler Configuration

Right-click over the project name to open the context menu and select the option Properties.

Select the option C/C++ General > Paths and Symbols and add the following include paths to all Languages and Configurations: 

${StudioSdkPath}/util/third_party/segger/systemview/Config
${StudioSdkPath}/util/third_party/segger/systemview/SEGGER
${StudioSdkPath}/util/third_party/segger/systemview/Sample/MicriumOSKernel
${StudioSdkPath}/util/third_party/segger/systemview/Sample/MicriumOSKernel/Config

 

 

Resolving a couple of conflicts by excluding some C Files from compilation

Locate the file SEGGER_SYSVIEW_Config_MicriumOSKernel.c in the Project Explorer at dev-cfg > source

Right click over the file SEGGER_SYSVIEW_Config_MicriumOSKernel.c to open the context menu and select the option Properties.

Select the option C/C++ Build and exclude this file from compilation by selecting the checkbox Exclude resource from build.

Similarly, locate the file SEGGER_RTT.c in the Project Explorer at debug-basic-library > EFR32

Right click over the file SEGGER_RTT.c to open the context menu and select the option Properties.

Select the option C/C++ Build and exclude this file from compilation by selecting the checkbox Exclude resource from build.

 

 

Enabling the Trace Recorder

Open the file os_cfg.h located at the following path:

STUDIO_SDK_LOC\protocol\zigbee\app\framework\plugin-soc\micrium-rtos\config\os_cfg.h

 

Locate and set the macro OS_CFG_TRACE_EN to DEF_ENABLED

 

 

Finding the memory address of the RTT block

Re-compile your project and launch a Debug Session.

Click the button Probe located on the top toolbar of Simplicity Studio.

Once Probe is opened, type in the keyword _RTT in the Symbol Browser panel in Probe (at the bottom of the application) and make a note of the memory address as illustrated in the image below:

 

 

Starting a Recording

Start SystemView.

Press F5 to start a recording.

Select the option Address for the RTT Control Block Detection and enter the address you found with Probe as shown below:

 

It may be that as the DMP SDK and/or Simplicity Studio evolve, the tool to insert SystemView automatically finally works. I will keep checking if that's the case and I will delete this blog if it's no longer relevant. In the meantime, I hope it will help someone.

 

Disclaimer: The views, thoughts, and opinions expressed in this blog belong solely to the author, and not necessarily to Silicon Labs.

 

We have yet to see the full-fledged economic value of billions of new IoT devices entering multiple industries, though we can prepare ourselves with what we know will come along with it. As with any new innovation and/or market, malicious adversaries and attackers will lurk and invade for their own piece of the pie.

Despite the looming security threats, companies and developers designing new IoT products often like to focus their attention on the application itself versus proper security. Security slows the time-to-market and is often viewed as inconvenient because it increases cost.

But no one wants to design an application that’s prone to hacking or data theft. Undesirable events like high-profile hacks can lead to serious brand damage and loss of customer trust, and worst-case is a slow down or permanent reduction in the adoption of IoT.

When it comes to security, IoT is no different than previous technology innovations such as PCs, smartphones, and the Internet itself. If security is not addressed sufficiently by the creators of the technology – in this case, IoT product designers - the oversight could have devastating effects on the entire market, and it will no doubt have negative consequences for the individual companies opting to design irresponsibly.

Varying Degrees of Security

To avoid these scenarios, designers need to change how they view IoT security. Unfortunately, it’s not as simple as a “to have or not to have” decision. Security is not binary. The reality is there are many different levels of security. A device can only be considered secure in the context of an attacker, when the level of security is higher than the capabilities of the attacker.

Moreover, the capabilities of the attacker are typically non-static, and therefore, the security level will change over time. The improved capabilities of the attacker can come about in several different ways, from the discovery and/or publication of issues and vulnerabilities to broader availability of equipment and tools.

History has taught us some valuable lessons about how fast security threats can change for an object. A typical lifetime of an IoT-device depends on the application, but in industrial applications, 20 years is a common timeframe. A device launched in 1998, for example, was once only vulnerable to nation-state attacks; today it must be able to withstand DPA attacks by hobbyists with $300 for tools, some spare time and lots of coffee. Predicting the future capabilities of a class of adversaries is very difficult if not impossible, especially over a 20-year timespan. How does the adversary look in 2040? One might speculate if it is even human?

Bootloader Benefits

The only reasonable way to counter future attack scenarios is for the security of the device to evolve with the increased capabilities of the adversary. This requires IoT security with upgradable software.

Of course, there is functionality requiring hardware primitives, which cannot be retrofitted via software updates. However, it is incredible what can be solved in software when the alternative is a truck-roll. Though, it impossible to predict and account for all future attacks.

Secure updates involve authenticating, integrity checking, and potentially encrypting the software for the device. The software handling such security updates is the bootloader, typically referred to as a secure bootloader. The secure bootloader itself, along with its corresponding cryptographic keys, constitutes the root-of-trust in the system and needs to have the highest level of security. A secure bootloader is functionality IoT vendors should expect to get from the IC manufacturers.

The authentication and integrity check should be implemented using asymmetric cryptography, with only public keys in the device. This way, it is not necessary to protect the signature-checking key in the devices. Since protecting keys in deployed devices is (or at least should be) harder than protecting keys in control of the device owner, it is also acceptable to use the same bootloader keys for many devices.

Encrypting the Software

Encrypting the software running on the IoT device has two benefits. First, it protects what vendors consider to be intellectual property (IP) from both competitors and counterfeiting. Secondly, encryption makes it more difficult for adversaries to analyze the software for vulnerabilities. Encrypting the new software for secure boot does; however, involve secret keys in the device, and protecting secret keys inside a device in the field is becoming increasingly harder. At the same time, newer devices have increased resistance to DPA attacks. Furthermore, a common countermeasure against DPA attacks is limiting the number of cryptographic operations that can take place to make it infeasible to get sufficient data to leak the key. Even though protecting the key is difficult and motivated adversaries will likely extract it, key protection makes attacking more difficult for the attacker.

Another consequence of secure updates is the likely future need for more memory in the IoT device. This is a complicated trade-off for several reasons. First, software tends to expand to the memory available in the device. So, a larger memory device requires discipline from the software team to leave room for future updates. The other complication is the value of free memory in the future versus the device’s initial cost. More memory tends to increase the cost of the device. This cost must be justified both from the device maker and the consumer point of view.

Finally, it is important to have a plan for distributing the security updates. For most devices, these updates use the device’s existing Internet connection. But in some cases, this requires adding or using physical interfaces such as USB drives (i.e., sneakernet). It is also important to consider that the devices might be behind firewalls or in some cases disconnected from the Internet.

IoT device software is often fully owned and managed by the device maker, meaning the device maker should have proven processes in place to internally protect the signing keys and particularly those who can issue updates.

Securing the Future

There is no such as thing as a 100 percent secure-proof device, especially during the entire duration of a product’s lifecycle.

Yet it is possible to understand and prepare for the most likely threats and safeguard for future threats by designing in the ability for upgradable software updates. IoT developers must adopt themselves to this critical mindset of responsible security design. Otherwise, they are placing their innovations, and IoT’s market potential, into the hands of adversaries.

For more on upgradeable security, Silicon Labs’ senior director of product security Lars Lydersen hosted a webinar in which he provided the insight and background to help in evaluating what security functionality is necessary in an IoT design.