Tag Archives: security

Protecting products and intellectual property (IP) from attackers is a fairly new concept that many engineers have not yet had to face. It is only a matter of time, though, until products—which are becoming more embedded and integrated with the real world—become targets for attacks leading to theft of service, loss of revenue, or a damaged corporate reputation. Consumer electronics, financial and medical technology, and network products are all at risk.

In this article, I’ll focus on the “why” and the “what” of embedded security, also known as secure hardware. Why does it matter? Why is it important to you, the designer? In what ways can someone attack your product? Because you can’t incorporate secure design methods without understanding what you are protecting and why, this article is a fitting introduction to the complexities of embedded security.

Reading this article won’t turn you into a security expert overnight. Nor will it provide all the answers to your secure hardware design needs. But, it will help you understand the major classes of attack and the mindsets of potential attackers. Actual secure hardware mechanisms come in all shapes and sizes, ranging from tamper-resistant enclosures to embedded IC dies in PCBs (to make them more difficult to probe). I’ll discuss these in a future Circuit Cellar article.

What embedded security typically comes down to is this: Is the cost of a successful attack greater than the value of what’s being protected? I’ll present some guidelines to help you make a determination.

UNDERSTAND YOUR RISK

As with everything in engineering, embedded security is all about trade-offs—risk management, as they say in the business world. Are there components or data in your system that need to be protected? If so, how much is it worth to protect them?

Forget what the glossy marketing material says about security products. There’s never a single answer and a single product to solve everybody’s product security needs. Every product has its own threat risks and is susceptible to certain types of attacks. Before being able to make an educated, informed decision, you need to understand the threat, the value of the contents being protected, and the reason for protecting such contents. Essentially, weaker, more vulnerable devices should contain less valuable secrets.

For example, a priceless family heirloom might be stored in a fireproof and tool-resistant safe. However, it wouldn’t make much financial sense to purchase such a safe to store an easily replaceable, inexpensive piece of jewelry. By the same token, it wouldn’t be feasible to implement an extremely secure, multilayered hardware solution just to protect a single password that is used to access undocumented features in a mobile phone; but, it would be in order to protect a financial institution’s cryptographic keys used for encrypted communications whose theft could result in the loss of millions of dollars.

When defining the security envelope of your product, there are three questions you should ask yourself (or your design team). First, what needs to be protected? Identify the critical components in your circuit that need to be protected before you start construction. It’s extremely difficult to implement proper security mechanisms after the fact. Such components to protect may include specific algorithms, device identifiers, digital media, biometrics, cryptographic keys, or product firmware. In addition to protecting discrete data contents, you may be interested in implementing a secure product boot sequence, secure field programmability, or a secure remote-management interface. Be aware that in some cases, even noncritical portions of your design can unknowingly compromise the security of the system, especially if they fail in an unanticipated way.

Second, why is it being protected? In most situations, critical data is being protected to prevent a specific attack threat. Ignoring or overlooking the possibility of attack can lead to a vulnerable product. In some countries, protecting certain content may be a legislative requirement. For example, a medical device containing confidential patient information must be secured in order to meet the U.S. Health Insurance Portability and Accountability Act (HIPAA) requirements.

Finally, whom are you protecting against? The types of attackers vary, ranging from a curious, harmless hardware hacker to an entire group of researchers backed by a competitor, organized crime, or government. As such, it’s important to attempt to properly identify the skill level and theoretical goals of the primary attackers against your product.

As a designer, you have the challenging task and responsibility of creating and ensuring your system’s security. You must understand every possible aspect of the design and are typically constrained by technical, financial, and political agendas. Attackers have an easier job, which is to exploit insecurities in the system. They need only to discover one vulnerable area of the design, and they typically have few constraints on their methods. They’ll likely choose the attack that yields the best results in the easiest and most repeatable fashion.

CLASSES OF ATTACK

No system will ever be 100% secure. “Secure” simply can be defined as when the time and money required to break the product is greater than the benefits to be derived from the effort. Given enough determination, time, and resources, an attacker can break any system.

At the highest level, four classes of security threat exist, as described by C.P. Pfleeger in Security in Computing. Through interception (or eavesdropping) an attacker can gain access to protected information without opening the product. With embedded systems, this can be achieved by monitoring the external interfaces of the device and by analyzing compromising signals within electromagnetic radiation or current fluctuations. On a computer network, this can be done by illicitly copying data or through promiscuous mode network monitoring. Although a loss may be discovered fairly quickly for certain attacks, like credit card theft or spoofed user authentication, a silent interceptor might not leave any traces.

Interruption (or fault generation) is a threat because an asset of a product becomes unavailable, unusable, or removed. An example is the malicious destruction of a hardware device, the intentional erasure of program or data contents, or a denial-of-service network attack. Fault generation consists of intentionally provoking malfunctions, such as operating the device under abnormal environmental conditions, which may lead to the bypassing of certain security measures.

The third type of threat is modification, which involves tampering with a product’s asset. Modification is typically an invasive technique for both hardware (e.g., circuit modifications or microprobing) and software/firmware (e.g., changing the values of data or altering a program so that it performs a different computation).

Lastly, fabrication creates counterfeit assets in a product or system. Fabrication can come in many forms, including adding data to a device, inserting spurious transactions into a bus or interface, and a man-in-the-middle attack on a network. Sometimes these additions can be detected as forgeries, but if skillfully done, they may be indistinguishable from the real thing.

TYPICAL ATTACK GOALS

When a product is targeted, the attacker usually has a goal in mind. This may be a simple goal, such as reverse engineering the circuitry in order to personalize or customize the device, or a more dedicated one, such as retrieving cryptographic keys or sensitive product trade secrets.

The specific goal of an attack tends to fit into one of four categories. The first is competition (or cloning), which is a scenario in which an attacker (usually a competitor) reverse engineers or copies specific IP in order to gain an advantage in the marketplace. The goal is to improve a product by using the stolen technology or to sell lower-priced knockoffs. Common target areas are circuit board features and product firmware.

Theft-of-service attacks aim to obtain a service for free that usually requires payment. Examples include mobile phone cloning, bypassing copy protection schemes on video game systems, and modifying cable boxes to receive extra channels.

User authentication (or spoofing) attacks are typically focused on products that are used to verify the owner’s identity, such as an authentication token, smartcard, biometric reader, or one-time-password generator. The attacker’s main goal is to gain access to personalized data and systems by spoofing the identity of the legitimate user.

Privilege escalation (or feature unlocking) attacks are aimed at accessing the hidden/undocumented features of a product and increasing the amount of control given to the user without having legitimate credentials. For example, using specialized circuitry to communicate with a mobile phone to gain access to phone diagnostics or acquiring administrator access on a network appliance.

Generally, an attack is achieved in one of three ways. In a focused attack, the adversary brings the target product into a private location to analyze and attack it on his or her own time with little risk of being discovered. A focused attack is probably the most familiar type of attack. Consider a curious student modifying a piece of hardware in his dorm room or a more determined criminal in a laboratory attempting to crack encryption routines.

Lunchtime attacks often take place during a small window of opportunity, such as a lunch or coffee break. Typically, the attack would need to be completed in a short period of time, ranging from a few minutes to a few hours. Lunchtime attacks are risky because they are easily detected if the target product is missing or has visibly been tampered with. For example, if you check your coat at a restaurant, an attacker could remove your PDA, retrieve the desired data, and return the PDA to your coat pocket within a matter of minutes and without being detected. Another example is an attacker copying data from a target’s authentication token or USB thumb drive that they left on their desk while attending a meeting.

Finally, there’s the insider attack, which may come in the form of run-on fraud by a manufacturer (producing additional identical units of a product to be sold on the gray market) or a disgruntled employee willing to sabotage the product or sell critical information such as system firmware or encryption keys. Many, but not all, insider threats can be thwarted with strict compartmentalization of critical data, access control, and chain-of-custody policies.

PRODUCT ACCESS

There are many ways an attacker can gain access to your product, but it often corresponds directly to the attack goal and usually involves one of four methods. In the first instance, the attacker purchases the product through a retail outlet, often with no means of detection (e.g., paying with cash). Multiple products could be purchased, with the first few serving as disposable units to aid in reverse engineering or to discover any existing tamper mechanisms. This scenario may be financially prohibitive for low-budget attackers but is typical for most focused attacks.

In the second instance, the attacker rents or leases the product from a vendor, distributor, or rental company, often on a monthly basis. Most attack types are possible in this instance, but because there is a high risk of detection when the product is returned, attackers will be cautious not to tamper with it.

In some cases, the attacker does not own the target product. The product is in active operation and may belong to a specific person (e.g., a mobile phone or smartcard), but the attacker may have physical access to the product. This is the most difficult type of attack because risk of detection is high.

In the final scenario, the attacker does not have access to the product, so all attacks are performed remotely (e.g., through a wired or wireless network). The attacker does not require special hardware tools and can easily mask his location. The risk of detection is low. Remote access attacks are common against computer networking equipment and appliances, such as routers, firewalls, access points, web servers, and storage area networks.

UNDERSTAND THE ATTACKER

“The only way to stop an attacker is to think like one.” That’s a favorite saying of mine. An FBI profiler tries to put himself in the mind of his subject. You must do the same when figuring out what, if any, security features you need to implement in our design. Today, because of advances in technology, the lower cost of products, and easy access to once-specialized tools, attacks against hardware are becoming more prevalent.

Attackers can be classified into three groups depending on their expected abilities and strengths: class I (clever outsiders), class II (knowledgeable insiders), and class III (funded organizations). This classification is essentially an industry standard for describing attackers in an academic fashion.[1]

Class I attackers are often extremely intelligent but might have insufficient knowledge of the system. They might have access to only moderately sophisticated equipment. They often try to take advantage of an existing weakness in the system rather than try to create one. Sometimes referred to as “script kiddies” in the computer security industry, these attackers run preprogrammed scripts to exploit known security vulnerabilities instead of finding their own.

Class II attackers have a substantial amount of specialized technical education and experience. They have a decent knowledge of the product or system, and often have highly sophisticated tools and instruments for analysis.

Class III attackers are teams of specialists with related and complementary skills backed by great funding. They are capable of performing in-depth system analysis, designing sophisticated attacks, and using the most advanced analysis tools. They may use Class II adversaries as part of the attack team.

Table 1 is comparison of each attacker class against available resources. The table may help to visualize the capabilities of the various attacker groups.

Table 1: Take a look at each attacker class compared to available resources. As you can see, each class has specific capabilities that will play a part in determining your product’s risk of attack.[2]

ADDING SECURITY

Security is a process, not a product. Security must be designed into your product during the conceptual design phase, and it should be considered for every portion of the design. It must be continually monitored and updated in order to have the maximum effect against attacks. Security can’t be added to a product and forgotten about. The product won’t remain secure forever.

Many times, an engineering change will be made to the product circuitry or firmware without a reevaluation of system security. Without a process in place to analyze changes throughout the design cycle, security that was properly implemented at the beginning of the design may become irrelevant by the time the product goes into production.

The primary concern is to incorporate risk analysis and security considerations into each step of your product’s development life cycle. Five principles, which are based on recommendations from the National Institute of Standards and Technology, serve as a good checklist. For more information, refer to “Engineering Principles for Information Technology Security (A Baseline for Achieving Security)” by G. Stoneburner et al. Let’s take a look at each one.

First, treat security as an integral part of your overall product design. It’s extremely difficult to implement security measures properly and successfully after a system has been developed.

Second, reduce risk to an acceptable level. Elimination of all risk is not cost-effective and likely impossible because nothing is 100% secure. A cost-benefit analysis should be conducted for each proposed secure hardware mechanism to ensure that it is performing its intended task at a desired cost.

Next, implement layered security. (Ensure no single point of failure.) Consider a layered approach of multiple security mechanisms to protect against a specific threat or to reduce overall vulnerability.

Fourth, minimize the system elements you’re relying on. Security measures include people, operations, and technology. The system should be designed so that a minimum number of elements need to be trusted in order to maintain protection. Put all your eggs in one basket by isolating all critical content in one secure area (physical or virtual) instead of having multiple secure areas throughout the design. This way, you can focus on properly securing and testing a single critical area of the product instead of numerous disparate areas.

Finally, don’t implement unnecessary security mechanisms. Every security mechanism should support one or more defined goals. Extra measures should not be implemented if they do not support a goal because they could add unneeded complexity to the system and are potential sources of additional vulnerabilities.

KEYS TO THE KINGDOM

Understanding and evaluating the risks and threats against your product is the first step toward a successful secure hardware design. There are many combinations of potential vulnerabilities, and it’s impossible to prevent against all of them. The good news is that vendors have recognized the need for embedded security, and we’re starting to see ICs and modules that reflect that. The more you can spread the word to your colleagues about making secure products, the safer all of us will be.

I’ve just started to scratch the surface of the embedded security topic. In a future article, I’ll take a no-nonsense look at a wide variety of practical secure hardware design solutions that you can implement in your product.

Joe Grand specializes in embedded system design, computer security research, and inventing new concepts and technologies. Joe holds a B.S.C.E. from Boston University. This article first appeared in Circuit Cellar 169, 2004.

Intended to address security concerns in Industrial Internet of Things (IIoT) systems, Maxim Integrated Products’s MAXREFDES143# embedded security reference design enables you to protect your designs against counterfeit sensor data. Intended to simplify the development of secure, authenticated sensor-to-web data, the design is well suited for analog sensor node and data authentication in a variety of applications, including factory automation and industrial processing.

The reference design features a two-stage hierarchical architecture, an Arduino-compatible hardware interface, and ARM mbed libraries. The architecture consists of a shield that communicates to a web server and a protected sensor node for data acquisition and authentication. The shield comprises the following:

Security is one of the hot topics today in the Internet of Things (IoT). There have been well-publicized security breaches of consumer devices that include hijacked video from wireless baby monitors being posted on the Internet and home automation systems that reveal whether a home is occupied or not. A number of systems have been breached just to demonstrate their vulnerabilities. Less well publicized are security breaches of industrial equipment with much more severe consequences. These are rarely made public for obvious reasons.

At first glance, it would seem that the existing security mechanism for the Internet and corporate networks would be an easy solution for IoT security. There are several problems with this. First, IoT applications only require security that is “good enough” for the specific application. Just like you don’t need razor wire and guard towers to keep your dog in the yard and don’t want to rely on a four foot yard fence to keep the prisoners in a maximum security prison, the level of security for an IoT product needs to be based on the needs of the application (often basic privacy rather than real security).

Consider data encryption for network transfers as an example of why existing security mechanisms generally do not work well for the IoT. Encryption standards typically target applications that require extremely high levels of security such as financial transactions and military or national security communications. These encryption standards are severe overkill for most IoT applications and present significant problems for small, battery-powered IoT devices. An encryption algorithm may require upwards of 4 KB of code space, which is as much or more than many otherwise suitable microcontrollers might have. Many encryption standards rely on multiple rounds of encryption. The time it takes to perform the encryption could be several times longer on a small micro than the time it takes the micro to perform its main tasks. Most common encryption standards rely on 16- to 32-byte keys to help ensure data security. For many IoT devices, these key lengths could increase the length of their network messages by a factor of 4× to 8× or more. The execution time and added network traffic can quickly chew-up precious battery capacity, increasing the size and cost of a product. The extremely high level of security provided by these encryption algorithms is what drives the large code size, long execution times, and high message overhead that makes them inappropriate for most IoT applications. Hardware encryption addresses the code size and execution time issues but still suffers from high message overhead.

The other major problem with using existing security mechanisms is IoT developers typically don’t have network security experience. There is a certain mindset and expertise required to develop IoT products and a completely different mindset and expertise required to be a security expert. The time required to develop these security mechanisms in-house could take several times longer than the basic product development. Several companies have recognized this problem and have recently introduced security framework products to be incorporated into IoT devices. True end-to-end security requires much more than just passwords and data encryption, and these framework products address other needs like key management and protection against common network attacks. These security frameworks may well be the future of IoT security, but to be widely adopted, they have to be right-sized for IoT devices.

When selecting the wireless technology to use in an IoT product, things like distance, bandwidth, cost, and physical size have to be considered. Words and phrases like “streamlined” and “light weight” need to be kept in mind when assessing security solutions for IoT products. A feature-rich security framework product might be appealing, but many IoT devices provide simple functions and don’t need a plethora of features. They also can’t afford the memory space and execution time overhead (and power consumption) imposed by these unneeded features. Whether future IoT products are based on a security framework or in-house developed security, there will not be a one-size-fits-all solution. Security for successful IoT products will be right-sized for the hardware resources available and the needs of the application.

Mike Lease is a hardware/firmware engineer with more than 30 years of product development experience, mostly in embedded products. He developed a number of battery-powered, wirelessly connected devices before “IoT” became a common buzzword, and several more since then. Mike enjoys taking on tough challenges and has recently developed a fascination with generating random numbers. In 2013 he founded CMicrotek (www.cmicrotek.com) to develop a family of ultra-low current measurement products primarily for developers of battery-powered products. Mike recently launched LSE Technologies, a provider of lightweight stream encryption software for M2M and IoT applications.

When you talk about a startup, you likely envision bearded hipsters drinking fancy coffee at their expensive Macs. But not all startups are cut from the same cloth. Consider the following case. We recently met with a small team of talented long-time engineers in Madrid that is swimming against the tide. After working for many years in the electronics design industry, the engineers now innovating secure hardware products at a startup with big ideas and lofty goals.

With the onset of Internet of Things (IoT) technology, an enormous number of devices are now accessible via the Internet and are therefore vulnerable to cyberattack. Society is still adjusting to the fact that devices that people used to trust can now betray them in unexpected ways. Your television may expose your conversations, your printer may divulge your documents, and your fitness monitor may reveal your health information. All of these attacks become possible in the presence of IoT devices which are not designed with security in mind. System designers are trained to evaluate system design options in terms of their impact on system characteristics such as power, performance, and time-to-market, but security is a property which is less well understood. Designers of IoT devices need to have the ability to consider, both qualitatively and quantitatively, how design alternatives affect the security of the system. To do that, designers must understand the essential aspects of common cyberattacks.

The nature of cyberattacks is broad and ever-changing as attackers alter their techniques over time. However, there are a number of attack themes which are fundamental to many cyberattacks and change only infrequently. Designers need to understand these important attack themes and how to defend against them. A good example is a vulnerability to a buffer overflow attack which is usually a result of weak coding practices, such as neglecting to verify that the amount of data written into a buffer is not greater than the size of the buffer. Defense against buffer overflow can likely be achieved through static code analysis and proper testing techniques, without the need to include any security components in the IoT device.

Another attack against IoT devices is a battery draining attack which consumes power by exploiting features of the network communication protocol being used by the device. Different protocols, and their interface controllers, have different degrees of vulnerability to such attacks, and the system designer needs to be aware of this when selecting a communication protocol.

This essay appears in Circuit Cellar 309, April 2016. Subscribe to Circuit Cellar to read project articles, essays, interviews, and tutorials every month!

Defending against some attacks will require the use of software and hardware components which are dedicated to security-related tasks. Such components incur overheads which must be considered by the designer. A common example is whether or not to use encryption, what type of encryption, and whether that encryption should be implemented in hardware or software. Besides the power and cost trade-offs involved, the designer will need to be able to estimate how well each type of encryption protects the system from, for example, a man-in-the-middle attack which intercepts communications with other devices.

IoT security is clearly an important design property which must be considered by designers who understand the complexities of cybersecurity. A problem for the field of IoT is that there is a shortage of IoT designers who understand cybersecurity. There is a range of possible solutions to address the shortage problem which vary based on who takes responsibility to find a solution. One alternative is education or training to ensure that designers are aware of the complexities of the security problem and can address them during the design process. Individual IoT designers may take responsibility for their own training, which means that the designer will individually seek out learning materials and possibly courses. As a professor I feel that individuals should always take responsibility for their own education, but in practice this is difficult and may not consistently result in the best outcome for all concerned. An individual who is not familiar with security will have a hard time determining what is important to learn and what is not, so they may waste time and money on education with no real value. In my role as Vice Chair of Undergraduate Studies, I am frequently asked about what a student needs to learn to be productive in industry, but if an individual cannot find an appropriate mentor to provide them with some direction, then their attempts at education may not be fruitful.

Another alternative is to place the responsibility for the development of secure IoT devices on the companies which employ the designers and sell the IoT devices. For this to happen, company managers must first accept that security costs money and that security is worth some expenditure. As long as security is seen as an overhead with no direct financial benefit, industry is not be motivated to make the necessary changes to build secure systems. Too often, security is largely ignored until a successful cyberattack against a company is publicized and the company suffers in terms of reputation and possible lawsuits. Industry needs to accept the importance of security upfront to avoid the more significant costs of dealing with successful attacks.

Companies can take several different approaches to ensuring security including guaranteeing that their designers are appropriately knowledgeable about IoT security. A salary premium for security experts could motivate employees to take responsibility for their own security education. In-house corporate training can be provided to employees whose job responsibilities necessitate an understanding of security. Employers can outsource and pay for education at local or online schools. When a project is particularly security-sensitive requiring more expertise than is available internally, a contractor with the appropriate security expertise can be brought in. All of these options incur different costs which would need to be justified by the need for security in the market where the IoT devices will be used.

Eventually, a mixture of these approaches should be employed to achieve the best, and most secure, results. Individual designers need to make every effort to learn about security issues, and employers need to motivate them with appropriate salaries and facilitate their efforts by providing opportunities for education. The lack of security of current IoT devices has been used as an argument against their adoption, but there seems to be no stopping the growing use of the IoT. At the same time, cyberattacks are also growing in number, sophistication, and financial impact. Security needs to be a first-class design consideration for IoT systems, on par with cost, power, and the other constraints that embedded designers have always dealt with.

Associate Professor Ian G. Harris earned a BS in Computer Science at MIT and MS and PhD degrees in Computer Science from the University of California San Diego. He is currently Vice Chair of Undergraduate Education in the Computer Science Department at the University of California Irvine. His research group focuses on the security and verification of Internet of Things systems. He also teaches an IoT specialization entitled “An Introduction to Programming the Internet of Things.”

Microsoft currently uses Infineon Technologies OPTIGA Trusted Platform Modules (TPMs) in its newest personal computing devices, including the Surface Pro 4 tablet and the Surface Book. The dedicated security chips store sensitive data, including keys, certificates, and passwords and keeps them separated from the main processor, which further secures the system from unauthorized access, manipulation, and data theft. For example, the Microsoft BitLocker Drive Encryption application’s key and password are stored in the TPM.

Microsoft’s personal computing devices rely on the OPTIGA TPM SLB 9665, which is the first certified security controller based on TPM 2.0. This standard was defined by the Trusted Computing Group (TCG).

UltraSoC recently announced Bare Metal Security capabilities to extend its on-chip monitoring and analytics to deliver security functionality required in a broad range of embedded products (e.g., IoT appliances and enterprise systems). Bare Metal Security features are implemented as hardware running below the operating system, so they’re nonintrusive even if the system’s conventional security measures are compromised. This adds an entirely new level of protection for the system-on-chip (SoC).

Bare Metal Security functionality uses the UltraSoC monitors to watch for unexpected behaviors such as suspicious memory accesses or processor activity, at hardware speed and nonintrusively, with minimal silicon overhead. Because it is an orthogonal on-chip hardware infrastructure independent of the main system functionality and software, there is no negative impact on system performance and it is very difficult for an attacker to subvert or tamper with. Although it functions below and outside of the operating system, the technology also provides a means of communicating with software on the device as part of a holistic security system, if this is necessary. Bare-Metal Security features also provide visibility of the whole system, making it extremely difficult to camouflage or hide an attack.

By offering resource-efficient and highly effective protection against malicious attack and malfunction, the UltraSoC on-chip analytics and monitoring system provides both development support and functionality enhancement from the same on-chip blocks. Teams already using UltraSoC to accelerate the debug, silicon validation, and bring-up process can use the same infrastructure for security processing. Designers who need Bare Metal Security features get the development benefits of a vendor-independent on-chip debug infrastructure at zero additional cost.

Although originally developed for debug and silicon validation, UltraSoC’s IP also enables a broad range of value-added functionality in-service, of which security is just one example. Other applications include in-field monitoring, performance optimization, reducing power utilization and SLA enforcement.

BittWare recently announced two new boards in its Altera Arria 10 FPGA product roadmap to complement their existing Arria 10 3U VPX and PCIe offerings: A10PED and A10XM4.

The A10PED Dual Arria 10 PCIe full-length Gen3 x16 Card supporting either the 660 or 1150 KLE size FPGAs (GX), with one supporting an optional SoC (SX) with dual ARM. Primarily targeting signal and network packet processing applications the board provides 28 lanes of serial I/O up to 10.325 Gbps each, with support for high-accuracy time stamping. Featuring 4x 260-pin DDR4 SODIMMs and a Hybrid Memory Cube (HMC), the A10PED will support up to 68 GB of memory with a peak aggregate memory bandwidth of over 175 GB/sec (not including I/O or PCIe). For latency-sensitive applications, some or all of the DDR4 SODIMMs can be replaced with proprietary QDR-II/IV SRAM SODIMMs. These memory options, coupled with full support for Altera’s OpenCL tools, also make this board compelling for acceleration & co-processing applications.

The A10XM4 Arria 10 XMC (VITA 42) Module provides network interface (NIC) and cyber/security capabilities in addition to host/carrier acceleration for applications in radar, EW, networking, and SigInt. In addition, it will support full conduction cooling. Compatible with any standard XMC carrier, the A10XM4 features an Arria 10 GX FPGA with two lanes of 10 GigE, along with up to 16 GB of memory and PCIe Gen3 x8 PCIe to the host. BittWare’s NIC application example and OpenCL BSP will greatly simplify the integration and development of cyber/security additions to and off-loading of standard host applications.

The A10PED full length PCIe board will be available Q4 2015 and the A10XM4 XMC board will be available Q1 2016. Contact BittWare for configurations, pricing, and details.

Eight memory sockets are provided to support VLP DDR3-1333 REG/ECC up to 128 GB and data transfer bandwidth up to 320 Gbps. The aTCA-N700 blade also supports TCAM for fast router lookup. The blade features a powerful local management processor (LMP) and a quad-core Freescale Semiconductor QorIQ P2041, which makes local management more flexible and convenient and enables the Cavium processors to focus on packet processing.

Each set of NPUs features its own NOR boot flash memory and NAND OS flash memory in a redundant configuration. The LMP has two EEROM for U-Boot image storage and two SSD devices for operating system and application image storage.

Marilyn Wolf has created embedded computing techniques, co-founded two companies, and received several Institute of Electrical and Electronics Engineers (IEEE) distinctions. She is currently teaching at Georgia Institute of Technology’s School of Electrical and Computer Engineering and researching smart-energy grids.—Nan Price, Associate Editor

NAN: Do you remember your first computer engineering project?

MARILYN: My dad is an inventor. One of his stories was about using copper sewer pipe as a drum memory. In elementary school, my friend and I tried to build a computer and bought a PCB fabrication kit from RadioShack. We carefully made the switch features using masking tape and etched the board. Then we tried to solder it and found that our patterning technology outpaced our soldering technology.

NAN: You have developed many embedded computing techniques—from hardware/software co-design algorithms and real-time scheduling algorithms to distributed smart cameras and code compression. Can you provide some information about these techniques?

Marilyn Wolf

MARILYN: I was inspired to work on co-design by my boss at Bell Labs, Al Dunlop. I was working on very-large-scale integration (VLSI) CAD at the time and he brought in someone who designed consumer telephones. Those designers didn’t care a bit about our fancy VLSI because it was too expensive. They wanted help designing software for microprocessors.

Microprocessors in the 1980s were pretty small, so I started on simple problems, such as partitioning a specification into software plus a hardware accelerator. Around the turn of the millennium, we started to see some very powerful processors (e.g., the Philips Trimedia). I decided to pick up on one of my earliest interests, photography, and look at smart cameras for real-time computer vision.

That work eventually led us to form Verificon, which developed smart camera systems. We closed the company because the market for surveillance systems is very competitive.
We have started a new company, SVT Analytics, to pursue customer analytics for retail using smart camera technologies. I also continued to look at methodologies and tools for bigger software systems, yet another interest I inherited from my dad.

NAN: Tell us a little more about SVT Analytics. What services does the company provide and how does it utilize smart-camera technology?

MARILYN: We started SVT Analytics to develop customer analytics for software. Our goal is to do for bricks-and-mortar retailers what web retailers can do to learn about their customers.

On the web, retailers can track the pages customers visit, how long they stay at a page, what page they visit next, and all sorts of other statistics. Retailers use that information to suggest other things to buy, for example.

Bricks-and-mortar stores know what sells but they don’t know why. Using computer vision, we can determine how long people stay in a particular area of the store, where they came from, where they go to, or whether employees are interacting with customers.

Our experience with embedded computer vision helps us develop algorithms that are accurate but also run on inexpensive platforms. Bad data leads to bad decisions, but these systems need to be inexpensive enough to be sprinkled all around the store so they can capture a lot of data.

NAN: Can you provide a more detailed overview of the impact of IC technology on surveillance in recent years? What do you see as the most active areas for research and advancements in this field?

MARILYN: Moore’s law has advanced to the point that we can provide a huge amount of computational power on a single chip. We explored two different architectures: an FPGA accelerator with a CPU and a programmable video processor.

We were able to provide highly accurate computer vision on inexpensive platforms, about $500 per channel. Even so, we had to design our algorithms very carefully to make the best use of the compute horsepower available to us.

Computer vision can soak up as much computation as you can throw at it. Over the years, we have developed some secret sauce for reducing computational cost while maintaining sufficient accuracy.

NAN: You wrote several books, including Computers as Components: Principles of Embedded Computing System Design and Embedded Software Design and Programming of Multiprocessor System-on-Chip: Simulink and System C Case Studies. What can readers expect to gain from reading your books?

MARILYN: Computers as Components is an undergraduate text. I tried to hit the fundamentals (e.g., real-time scheduling theory, software performance analysis, and low-power computing) but wrap around real-world examples and systems.

Embedded Software Design is a research monograph that primarily came out of Katalin Popovici’s work in Ahmed Jerraya’s group. Ahmed is an old friend and collaborator.

NAN: When did you transition from engineering to teaching? What prompted this change?

MARILYN: Actually, being a professor and teaching in a classroom have surprisingly little to do with each other. I spend a lot of time funding research, writing proposals, and dealing with students.

I spent five years at Bell Labs before moving to Princeton, NJ. I thought moving to a new environment would challenge me, which is always good. And although we were very well supported at Bell Labs, ultimately we had only one customer for our ideas. At a university, you can shop around to find someone interested in what you want to do.

NAN: How long have you been at Georgia Institute of Technology’s School of Electrical and Computer Engineering? What courses do you currently teach and what do you enjoy most about instructing?

MARILYN: I recently designed a new course, Physics of Computing, which is a very different take on an introduction to computer engineering. Instead of directly focusing on logic design and computer organization, we discuss the physical basis of delay and energy consumption.

You can talk about an amazingly large number of problems involving just inverters and RC circuits. We relate these basic physical phenomena to systems. For example, we figure out why dynamic RAM (DRAM) gets bigger but not faster, then see how that has driven computer architecture as DRAM has hit the memory wall.

NAN: As an engineering professor, you have some insight into what excites future engineers. With respect to electrical engineering and embedded design/programming, what are some “hot topics” your students are currently attracted to?

MARILYN: Embedded software—real-time, low-power—is everywhere. The more general term today is “cyber-physical systems,” which are systems that interact with the physical world. I am moving slowly into control-oriented software from signal/image processing. Closing the loop in a control system makes things very interesting.

My Georgia Tech colleague Eric Feron and I have a small project on jet engine control. His engine test room has a 6” thick blast window. You don’t get much more exciting than that.

NAN: That does sound exciting. Tell us more about the project and what you are exploring with it in terms of embedded software and closed-loop control systems.

MARILYN: Jet engine designers are under the same pressures now that have faced car engine designers for years: better fuel efficiency, lower emissions, lower maintenance cost, and lower noise. In the car world, CPU-based engine controllers were the critical factor that enabled car manufacturers to simultaneously improve fuel efficiency and reduce emissions.

Jet engines need to incorporate more sensors and more computers to use those sensors to crunch the data in real time and figure out how to control the engine. Jet engine designers are also looking at more complex engine designs with more flaps and controls to make the best use of that sensor data.

One challenge of jet engines is the high temperatures. Jet engines are so hot that some parts of the engine would melt without careful design. We need to provide more computational power while living with the restrictions of high-temperature electronics.

NAN: Your research interests include embedded computing, smart devices, VLSI systems, and biochips. What types of projects are you currently working on?

MARILYN: I’m working on with Santiago Grivalga of Georgia Tech on smart-energy grids, which are really huge systems that would span entire countries or continents. I continue to work on VLSI-related topics, such as the work on error-aware computing that I pursued with Saibal Mukopodhyay.

I also work with my friend Shuvra Bhattacharyya on architectures for signal-processing systems. As for more unusual things, I’m working on a medical device project that is at the early stages, so I can’t say too much specifically about it.

NAN: Can you provide more specifics about your research into smart energy grids?

MARILYN: Smart-energy grids are also driven by the push for greater efficiency. In addition, renewable energy sources have different characteristics than traditional coal-fired generators. For example, because winds are so variable, the energy produced by wind generators can quickly change.

The uses of electricity are also more complex, and we see increasing opportunities to shift demand to level out generation needs. For example, electric cars need to be recharged, but that can happen during off-peak hours. But energy systems are huge. A single grid covers the eastern US from Florida to Minnesota.

To make all these improvements requires sophisticated software and careful design to ensure that the grid is highly reliable. Smart-energy grids are a prime example of Internet-based control.

We have so many devices on the grid that need to coordinate that the Internet is the only way to connect them. But the Internet isn’t very good at real-time control, so we have to be careful.

We also have to worry about security Internet-enabled devices enable smart grid operations but they also provide opportunities for tampering.

NAN: You’ve earned several distinctions. You were the recipient of the Institute of Electrical and Electronics Engineers (IEEE) Circuits and Systems Society Education Award and the IEEE Computer Society Golden Core Award. Tell us about these experiences.

MARILYN: These awards are presented at conferences. The presentation is a very warm, happy experience. Everyone is happy. These things are time to celebrate the field and the many friends I’ve made through my work.

The GP490 is an ultra-low-power ZigBee PRO communication controller. It supports the ZigBee PRO chip features, including bidirectional commissioning, bidirectional communication, and full security mode.

The controller is specifically designed for low-power smart home applications including door, window, and temperature sensors and light switches. Equipped with the energy-optimized GP490, these low-power, low-data rate smart home applications can operate on a coin cell battery for more than 10 years.

The GP490 development kit with reference design and software can help device manufacturers build low-cost, low-power sensor nodes, optimized for standard battery and coin-cell battery operation. Guidelines and tools are provided to ensure an efficient ZigBee certification for a cost-optimized feature set of the ZigBee Home Automation (HA 1.2) Application Profile.

Every few days we you a sneak peek at some of the exciting content that will run in Circuit Cellar‘s Anniversary issue, which is scheduled to be available in early 2013. You’ve read about Ed Nisley’s essay on his most memorable designs—from a hand-held scanner project to an Arduino-based NiMH cell tester—and Robert Lacoste’s tips for preventing embedded design errors. Now it’s time for another preview.

Many engineers know they are building electronic systems for use in dangerous times. They must plan for both hardware and software attacks, which makes embedded security a hot topic for 2013. In an essay on embedded security risks, Virginia Tech professor Patrick Schaumont looks at the current state of affairs through several examples. His tips and suggestions will help you evaluate the security needs of your next embedded design.

Schaumont writes:

As design engineers, we should understand what can and what cannot be done. If we understand the risks, we can create designs that give the best possible protection at a given level of complexity. Think about the following four observations before you start designing an embedded security implementation.

First, you have to understand the threats that you are facing. If you don’t have a threat model, it makes no sense to design a protection—there’s no threat! A threat model for an embedded system will specify what can attacker can and cannot do. Can she probe components? Control the power supply? Control the inputs of the design? The more precisely you specify the threats, the more robust your defenses will be. Realize that perfect security does not exist, so it doesn’t make sense to try to achieve it. Instead, focus on the threats you are willing to deal with.

Second, make a distinction between what you trust and what you cannot trust. In terms of building protections, you only need to worry about what you don’t trust. The boundary between what you trust and what you don’t trust is suitably called the trust boundary. While trust boundaries where originally logical boundaries in software systems, they also have a physical meaning in embedded context. For example, let’s say that you define the trust boundary to be at the chip-package level of a microcontroller. This implies that you’re assuming an attacker will get as close to the chip as the package pins, but not closer. With such a trust boundary, your defenses should focus on off-chip communication. If there’s nothing or no one to trust, then you’re in trouble. It’s not possible to build a secure solution without trust.

Third, security has a cost. You cannot get it for free. Security has a cost in resources and energy. In a resource-limited embedded system, this means that security will always be in competition with other system features in terms of resources. And because security is typically designed to prevent bad things from happening rather than to enable good things, it may be a difficult trade-off. In feature-rich consumer devices, security may not be a feature for which a customer is willing to pay extra.

The fourth observation, and maybe the most important one, is to realize is that you’re not alone. There are many things to learn from conferences, books, and magazines. Don’t invent your own security. Adapt standards and proven Circuit Cellar’s Circuit Cellar 25th Anniversary Issue will be available in early 2013. Stay tuned for more updates on the issue’s content.techniques. Learn about the experiences of other designers.

Passwords establish the identity of a user, and they are an essential component of modern information technology. In this article, I describe one-time passwords: passwords that you use once and then never again. Because they’re used only once, you don’t have to remember them. I describe how to implement one-time passwords with a Texas Instruments (TI) eZ430-Chronos wireless development tool in a watch and how to use them to log in to existing web services such as Google Gmail (see Photo 1).

Photo 1—The Texas Instruments eZ430 Chronos watch displays a unique code that enables logging into Google Gmail. The code is derived from the current time and a secret value embedded in the watch.

To help me get around on the Internet, I use a list of about 80 passwords (at the latest count). Almost any online service I use requires a password: reading e-mail, banking, shopping, checking reservations, and so on. Many of these Internet-based services have Draconian password rules. For example, some sites require a password of at least eight characters with at least two capitals or numbers and two punctuation characters. The sheer number of passwords, and their complexity, makes it impossible to remember all of them.

What are the alternatives? There are three different ways of verifying the identity of a remote user. The most prevailing one, the password, tests something that a user knows. A second method tests something that the user has, such as a secure token. Finally, we can make use of biometrics, testing a unique user property, such as a fingerprint or an eye iris pattern.

Each of these three methods comes with advantages and disadvantages. The first method (passwords) is inexpensive, but it relies on the user’s memory. The second method (secure token) replaces the password with a small amount of embedded hardware. To help the user to log on, the token provides a unique code. Since it’s possible for a secure token to get lost, it must be possible to revoke the token. The third method (biometrics) requires the user to enroll a biometric, such as a fingerprint. Upon login, the user’s fingerprint is measured again and tested against the enrolled fingerprint. The enrollment has potential privacy issues. And, unlike a secure token, it’s not possible to revoke something that is biometric.

The one-time password design in this article belongs to the second category. A compelling motivation for this choice is that a standard, open proposal for one-time passwords is available. The Initiative for Open Authentication (OATH) is an industry consortium that works on a universal authentication mechanism for Internet users. They have developed several proposals for user authentication methods, and they have submitted these to the Internet Engineering Task Force (IETF). I’ll be relying on these proposals to demonstrate one-time passwords using a eZ430-Chronos watch. The eZ430-Chronos watch, which I’ll be using as a secure token, is a wearable embedded development platform with a 16-bit Texas Instruments MSP430 microcontroller.

ONE-TIME PASSWORD LOGON

Figure 1 demonstrates how one-time passwords work. Let’s assume a user—let’s call him Frank—is about to log on to a server. Frank will generate a one-time password using two pieces of information: a secret value unique to Frank and a counter value that increments after each authentication. The secret, as well as the counter, is stored in a secure token. To transform the counter and the secret into a one-time password, a cryptographic hash algorithm is used. Meanwhile, the server will generate the one-time password it is expecting to see from Frank. The server has a user table that keeps track of Frank’s secret and his counter value. When both the server and Frank obtain the same output, the server will authenticate Frank. Because Frank will use each password only once, it’s not a problem if an attacker intercepts the communication between Frank and the server.

Figure 1—A one-time password is formed by passing the value of a personal secret and a counter through a cryptographic hash (1). The server obtains Frank’s secret and counter value from a user table and generates the same one-time password (2). The two passwords must match to authenticate Frank (3). After each authentication, Frank’s counter is incremented, ensuring a different password the next time (4).

After each logon attempt, Frank will update his copy of the counter in the secure token. The server, however, will only update Frank’s counter in the user table when the logon was successful. This will intercept false logon attempts. Of course, it is possible that Frank’s counter value in the secure token gets out of sync with Frank’s counter value in the server. To adjust for that possibility, the server will use a synchronization algorithm. The server will attempt a window of counter values before rejecting Frank’s logon. The window chosen should be small (i.e., five). It should only cover for the occasional failed logon performed by Frank. As an alternate mechanism to counter synchronization, Frank could also send the value of his counter directly to the server. This is safe because of the properties of a cryptographic hash: the secret value cannot be computed from the one-time password, even if one knows the counter value.

You see that, similar to the classic password, the one-time password scheme still relies on a shared secret between Frank and the server. However, the shared secret is not communicated directly from the user to the server, it is only tested indirectly through the use of a cryptographic hash. The security of a one-time password therefore stands or falls with the security of the cryptographic hash, so it’s worthwhile to look further into this operation.

CRYPTOGRAPHIC HASH

A cryptographic hash is a one-way function that calculates a fixed-length output, called the digest, from an arbitrary-length input, called the message. The one-way property means that, given the message, it’s easy to calculate the digest. But, given the digest, one cannot find back the message.

The one-way property of a good cryptographic hash implies that no information is leaked from the message into the digest. For example, a small change in the input message may cause a large and seemingly random change in the digest. For the one-time password system, this property is important. It ensures that each one-time password will look very different from one authentication to the next.

The one-time password algorithm makes use of the SHA-1 cryptographic hash algorithm. This algorithm produces a digest of 160 bits. By today’s Internet standards, SHA-1 is considered old. It was developed by Ronald L. Rivest and published as a standard in 1995.

Is SHA-1 still adequate to create one-time passwords? Let’s consider the problem that an attacker must solve to break the one-time password system. Assume an attacker knows the SHA-1 digest of Frank’s last logon attempt. The attacker could now try to find a message that matches the observed digest. Indeed, knowing the message implies knowing a value of Frank’s secret and the counter. Such an attack is called a pre-image attack.

Fortunately, for SHA-1, there are no known (published) pre-image attacks that are more efficient than brute force trying all possible messages. It’s easy to see that this requires an astronomical number of messages values. For a 160-bit digest, the attacker can expect to test on the order of 2160 messages. Therefore it’s reasonable to conclude that SHA-1 is adequate for the one-time password algorithm. Note, however, that this does not imply that SHA-1 is adequate for any application. In another attack model, cryptographers worry about collisions, the possibility of an attacker finding a pair of messages that generate the same digest. For such attacks on SHA-1, significant progress has been made in recent years.

The one-time password scheme in Figure 1 combines two inputs into a single digest: a secret key and a counter value. To combine a static, secret key with a variable message, cryptographers use a keyed hash. The digest of a keyed hash is called a message authentication code (MAC). It can be used to verify the identity of the message sender.

Figure 2 shows how SHA-1 is used in a hash-based message authentication code (HMAC) construction. SHA-1 is applied twice. The first SHA-1 input is a combination of the secret key and the input message. The resulting digest is combined again with the secret key, and SHA-1 is then used to compute the final MAC. Each time, the secret key is mapped into a block of 512 bits. The first time, it is XORed with a constant array of 64 copies of the value 0x36. The second time, it is XORed with a constant array of 64 copies of the value 0x5C.

Figure 2—The SHA-1 algorithm on the left is a one-way function that transforms an arbitrary-length message into a 160-bit fixed digest. The Hash-based message authentication code (HMAC) on the right uses SHA-1 to combine a secret value with an arbitrary-length message to produce a 160-bit message authentication code (MAC).

THE HOTP ALGORITHM

With the HMAC construction, the one-time password algorithm can now be implemented. In fact, the HMAC can almost be used as is. The problem with using the MAC itself as the one-time password is that it contains too many bits. The secure token used by Frank does not directly communicate with the server. Rather, it shows a one-time password Frank needs to type in. A 160-bit number requires 48 decimal digits, which is far too long for a human.

OATH has proposed the Hash-based one-time password (HOTP) algorithm. HOTP uses a key (K) and a counter (C). The output of HOTP is a six-digit, one-time password called the HOTP value. It is obtained as follows. First, compute a 160-bit HMAC value using K and C. Store this result in an array of 20 bytes, hmac, such that hmac[0] contains the 8 leftmost bits of the 160-bit HMAC string and hmac[19] contains the 8 rightmost bits. The HOTP value is then computed with a snippet of C code (see Listing 1).

Listing 1—C code used to compute the HTOP value

There is now an algorithm that will compute a six-digit code starting from a K value and a C value. HOTP is described in IETF RFC 4226. A typical HOTP implementation would use a 32-bit C and an 80-bit K.

An interesting variant of HOTP, which I will be using in my implementation, is the time-based one-time password (TOTP) algorithm. The TOTP value is computed in the same way as the HOTP value. However, the C is replaced with a timestamp value. Rather than synchronizing a C between the secure token and the server, TOTP simply relies on the time, which is the same for the server and the token. Of course, this requires the secure token to have access to a stable and synchronized time source, but for a watch, this is a requirement that is easily met.

The timestamp value chosen for TOTP is the current Unix time, divided by a factor d. The current Unix time is the number of seconds that have elapsed since midnight January 1, 1970, Coordinated Universal Time. The factor d compensates for small synchronization differences between the server and the token. For example, a value of 30 will enable a 30-s window for each one-time password. The 30-s window also gives a user sufficient time to type in the one-time password before it expires.

IMPLEMENTATION IN THE eZ430-CHRONOS WATCH

I implemented the TOTP algorithm on the eZ430-Chronos watch. This watch contains a CC430F6137 microcontroller, which has 32 KB of flash memory for programs and 4,096 bytes of RAM for data. The watch comes with a set of software applications to demonstrate its capabilities. Software for the watch can be written in C using TI’s Code Composer Studio (CCStudio) or in IAR Systems’s IAR Embedded Workbench.

The software for the eZ430-Chronos watch is structured as an event-driven system that ties activities performed by software to events such as alarms and button presses. In addition, the overall operation of the watch is driven through several modes, corresponding to a particular function executed on the watch. These modes are driven through a menu system.

Photo 2 shows the watch with its 96-segment liquid crystal display (LCD) and four buttons to control its operation. The left buttons select the mode. The watch has two independent menu systems, one to control the top line of the display and one to control the bottom line. Hence, the overall mode of the watch is determined by a combination of a menu-1 entry and a menu-2 entry.

Photo 2—With the watch in TOTP mode, one-time passwords are shown on the second line of the display. In this photo, I am using the one-time password 854410. The watch display cycles through the strings “totP,” “854,” and “410.”

Listing 2 illustrates the code relevant to the TOTP implementation. When the watch is in TOTP mode, the sx button is tied to the function set_totp(). This function initializes the TOTP timestamp value.

Listing 2—Code relevant to the TOTP implementation

The function retrieves the current time from the watch and converts it into elapsed seconds using the standard library function mktime. Two adjustments are made to the output of mktime, on line 11 and line 12. The first factor, 2208988800, takes into account that the mktime in the TI library returns the number of seconds since January 1, 1900, while the TOTP standard sets zero time at January 1, 1970. The second factor, 18000, takes into account that my watch is set to Eastern Standard Time (EST), while the TOTP standard assumes the UTC time zone—five hours ahead of EST. Finally, on line 14, the number of seconds is divided by 30 to obtain the standard TOTP timestamp. The TOTP timestamp is further updated every 30 s, through the function tick_totp().

The one-time password is calculated by compute_totp on line 33. Rather than writing a SHA1-HMAC from scratch, I ported the open-source implementation from Google Authenticator to the TI MSP 430. Lines 39 through 50 show how a six-digit TOTP code is calculated from the 160-bit digest output of the SHA1-HMAC.

The display menu function is display_totp on line 52. The function is called when the watch first enters TOTP mode and every second after that. First, the watch will recompute the one-time password code at the start of each 30-s interval. Next, the TOTP code is displayed. The six digits of the TOTP code are more than can be shown on the bottom line of the watch. Therefore, the watch will cycle between showing “totP,” the first three digits of the one-time password, and the next three digits of the one-time password. The transitions each take 1 s, which is sufficient for a user to read all digits.

There is one element missing to display TOTP codes: I did not explain how the unique secret value is loaded into the watch. I use Google Authenticator to generate this secret value and to maintain a copy of it on Google’s servers so that I can use it to log on with TOTP.

LOGGING ONTO GMAIL

Google Authenticator is an implementation of TOTP developed by Google. It provides an implementation for Android, Blackberry, and IOS so you can use a smartphone as a secure token. In addition, it also enables you to extend your login procedure with a one-time password. You cannot replace your standard password with a one-time password, but you can enable both at the same time. Such a solution is called a two-factor authentication procedure. You need to provide a password and a one-time password to complete the login.

As part of setting up the two-factor authentication with Google (through Account Settings – Using Two-Step Verification), you will receive a secret key. The secret key is presented as a 16-character string made up of a 32-character alphabet. The alphabet consists of the letters A through Z and the digits 2, 3, 4, 5, 6, and 7. This clever choice avoids numbers that can confused with letters (8 and B, for example). The 16-character string thus represents an 80-bit key.

I program this string in the TOTP design for the eZ430-Chronos watch to initialize the secret. In the current implementation, the key is loaded in the function reset_totp().

base32_decode((const u8 *)

”4RGXVQI7YVY4LBPC”, stotp.key, 16);

Of course, entering the key as a constant string in the firmware is an obvious vulnerability. An attacker who has access to a copy of the firmware also has the secret key used by the TOTP implementation! It’s possible to protect or obfuscate the key from the watch firmware, but these techniques are beyond the scope of this article. Once the key is programmed into the watch and the time is correctly set, you can display TOTP codes that help you complete the logon process of Google. Photo 1 shows a demonstration of logging onto Google’s two-step verification with a one-time password.

OTHER USES OF TOTP

There are other possibilities for one-time passwords. If you are using Linux as your host PC, you can install the OATH Toolkit, which implements the HOTP and TOTP mechanisms for logon. This toolkit enables you to install authentication modules on your PC that can replace the normal login passwords. This enables you to effectively replace the password you need to remember with a password generated from your watch.

Incidentally, several recent articles—which I have included in the resources section of this article—point to the limits of conventional passwords. New technologies, including one-time passwords and biometrics, provide an interesting alternative. With standards such as those from OATH around the corner, the future may become more secure and user-friendly at the same time.

Miami isn’t just a destination for the Heat vs. Thunder NBA Finals, world-renowned clubs, five-star restaurants, and professional beach lazing. It also boasts an evolving technology scene with tons of monthly events (e.g., game hackathons, app-building workshops). A notable contributor to the city’s culture of innovation is HackMiami, a hackerspace where professionals, students, and innovators can “invent/develop new technologies, develop new skills, enhance old skills, collaborate with other like minded individuals to create something that is better than what they can do on their own.”

The group’s multitalented members work on projects as diverse as secure servers and UAV designs (see video below).

Below are images Rod—one of the group’s members—submitted of the hackerpace.

HackMiami meets at the “Planet Linux Caffe” (Source: HackMiami)

HackMiami runs events such as workshops and contests such as the Homebrew Antenna Contest at DEFCON XX in Las Vegas, NV.

After reviewing the photo submissions, I asked Rod for a bit of info about the group. He quickly filled me in.C. J.: What are we looking at in the photos? Is that HackMiami’s actual space or are you holding an event a local establishment?

Rod: We hold our meetings at Planet Linux Caffe in Coral Gables, Florida. Planet Linux Caffe is a Open Source community place.

C. J.: What is the group’s “mission” or purpose?

Rod: We are hackerspace based in Miami, FL. We focus on information security and vulnerability research.

C. J.: What is your group like? Do members come from diverse tech backgrounds? How often do you meet?

A HackMiami meeting on the topic of cyber weapons (Source: HackMiami)

Rod: We have an open-door policy. Everybody welcome, we have people from ALL ages and ALL backgrounds. We meet every two weeks. Here is where we publish our meetings: meetup.com/hackmiami.

Rod: We have done some work with DD-WRT, Plug Servers, Pinapples, Arduino, etc.

C. J.: Tell us about the quadracopter project. When did you build it? How many group members were part of it? Can you tell our readers about some of the parts you used (e.g., MCU, motor controls, etc)?

Rod: This was done in December 2011. There were around five people involved in the project. The idea is in principle to create a network of communicating self resilient UAVs. Here is the list of the parts for the drone. For more information please contact Twitter handle @d1sc0rd1an.

Wrapping up, I mentioned to Rod that we’re always looking for interesting projects to share with the embedded design/programming community. He said HackMiami members likely will be working with Raspberry Pi in the near future. Sounds exciting. We can’t wait to see what the group develops.

Show us your hackerspace! Tell us about your group! Where does your group design, hack, create, program, debug, and innovate? Do you work in a 20′ × 20′ space in an old warehouse? Do you share a small space in a university lab? Do you meet a local coffee shop or bar? What sort of electronics projects do you work on? Submit your hackerspace and we might feature you on our website!