Michael Welle Wins the CC Code Challenge (Week 10)

We have a winner of last week’s CC Weekly Code Challenge, sponsored by IAR Systems! We posted a code snippet with an error and challenged the engineering community to find the mistake!

Congratulations to Michael Welle of Baden-Wurttemberg, Germany for winning the CC Weekly Code Challenge for Week 10! He’ll receive an IAR Kickstart: KSK-LPC4088-JL.

Michael’s correct answer was randomly selected from the pool of responses that correctly identified an error in the code. Michael answered:

Line 15: strcmp returns 0 if both strings are equal. On the other hand 0 is interpreted as false in C, so the condition is wrong. if (strcmp(a,b)==0)

There were a few possible solutions to this error. Good job everyone who identified them!

You can see the complete list of weekly winners and code challenges here.

What is the CC Weekly Code Challenge?
Each week, Circuit Cellar’s technical editors purposely insert an error in a snippet of code. It could be a semantic error, a syntax error, a design error, a spelling error, or another bug the editors slip in. You are challenged to find the error.Once the submission deadline passes, Circuit Cellar will randomly select one winner from the group of respondents who submit the correct answer.

Inspired? Want to try this week’s challenge? Get started!

Submission Deadline: The deadline for each week’s challenge is Sunday, 12 PM ESTRefer to the Rules, Terms & Conditions for information about eligibility and prizes.

Jon Chapman Wins the CC Code Challenge (Week 9)

We have a winner of last week’s CC Weekly Code Challenge, sponsored by IAR Systems! We posted a code snippet with an error and challenged the engineering community to find the mistake!

Congratulations to Jon Chapman of Ohio, United States for winning the CC Weekly Code Challenge for Week 9! He’ll receive a CCGold Archive on USB drive.

Jon’s correct answer was randomly selected from the pool of responses that correctly identified an error in the code. Jon answered:

Line 24: bgcolor tag is misspelled as ‘bgoclor’. It needs to be corrected to ‘bgcolor’

You can see the complete list of weekly winners and code challenges here.

What is the CC Weekly Code Challenge?
Each week, Circuit Cellar’s technical editors purposely insert an error in a snippet of code. It could be a semantic error, a syntax error, a design error, a spelling error, or another bug the editors slip in. You are challenged to find the error.Once the submission deadline passes, Circuit Cellar will randomly select one winner from the group of respondents who submit the correct answer.

Inspired? Want to try this week’s challenge? Get started!

Submission Deadline: The deadline for each week’s challenge is Sunday, 12 PM ESTRefer to the Rules, Terms & Conditions for information about eligibility and prizes.

CC Code Challenge (Week 8) Stumps Engineering Community

We stumped the engineering community with last week’s CC Weekly Code Challenge! We posted a code snippet with an error and challenged you to find the mistake!

Since nobody had the correct answer, we’ve drawn one lucky winner at random from all those who participated.

Congratulations to Marcelo Jimenez of Rio de Janeiro, Brazil for being selected in the CC Weekly Code Challenge – Week 7 drawing! He’ll receive a CC Tag Cloud t-shirt.

The language is Burroughs Corporation “Enhanced” Algol, a rather obscure language these days, though Algol variants were important in their time and are still discussed today in terms of their influence on the structure of subsequent programming languages. The correct answer was: Line 4: incorrect exponent character – it should be “2.99792458@8″

You can see the complete list of weekly winners and code challenges here.

What is the CC Weekly Code Challenge?
Each week, Circuit Cellar’s technical editors purposely insert an error in a snippet of code. It could be a semantic error, a syntax error, a design error, a spelling error, or another bug the editors slip in. You are challenged to find the error.Once the submission deadline passes, Circuit Cellar will randomly select one winner from the group of respondents who submit the correct answer.

Inspired? Want to try this week’s challenge? Get started!

Submission Deadline: The deadline for each week’s challenge is Sunday, 12 PM ESTRefer to the Rules, Terms & Conditions for information about eligibility and prizes.

Alex Ivopol Wins the CC Code Challenge (Week 7)

We have a winner of last week’s CC Weekly Code Challenge, sponsored by IAR Systems! We posted a code snippet with an error and challenged the engineering community to find the mistake!

Congratulations to Alex Ivopol of Wellington, New Zealand for winning the CC Weekly Code Challenge for Week 7! He’ll receive an IAR Kickstart KSK-TMPM061-JL kit.

Alex’s correct answer was randomly selected from the pool of responses that correctly identified an error in the code. Alex answered:

2013_code_challenge_07_answerYou can see the complete list of weekly winners and code challenges here.

What is the CC Weekly Code Challenge?
Each week, Circuit Cellar’s technical editors purposely insert an error in a snippet of code. It could be a semantic error, a syntax error, a design error, a spelling error, or another bug the editors slip in. You are challenged to find the error.Once the submission deadline passes, Circuit Cellar will randomly select one winner from the group of respondents who submit the correct answer.

Inspired? Want to try this week’s challenge? Get started!

Submission Deadline: The deadline for each week’s challenge is Sunday, 12 PM ESTRefer to the Rules, Terms & Conditions for information about eligibility and prizes.

Colm Baston Wins the CC Code Challenge (Week 6)

We have a winner of last week’s CC Weekly Code Challenge, sponsored by IAR Systems! We posted a code snippet with an error and challenged the engineering community to find the mistake!

Congratulations to Colm Baston of Flintshire, UK, for winning the CC Weekly Code Challenge for Week 6! He’ll receive the Elektor 2012 & 2011 Archive DVD.

Colm’s correct answer was randomly selected from the pool of responses that correctly identified an error in the code. Colm answered:

Line 7: (c == *s++) is comparing the values of c and *s rather than assigning: It should be (c = *s++)

You can see the complete list of weekly winners and code challenges here.

What is the CC Weekly Code Challenge?
Each week, Circuit Cellar’s technical editors purposely insert an error in a snippet of code. It could be a semantic error, a syntax error, a design error, a spelling error, or another bug the editors slip in. You are challenged to find the error.Once the submission deadline passes, Circuit Cellar will randomly select one winner from the group of respondents who submit the correct answer.

Inspired? Want to try this week’s challenge? Get started!

Submission Deadline: The deadline for each week’s challenge is Sunday, 12 PM ESTRefer to the Rules, Terms & Conditions for information about eligibility and prizes.

Antonios Chorevas Wins the CC Code Challenge (Week 5)

We have a winner of last week’s CC Weekly Code Challenge, sponsored by IAR Systems! We posted a code snippet with an error and challenged the engineering community to find the mistake!

Congratulations to Antonios Chorevas of Attiki, Greece, for winning the CC Weekly Code Challenge for Week 5! He’ll receive a CC “Tag Cloud” T-shirt and a hardcopy of the CC25 Anniversary Issue.

Antonios’ correct answer was randomly selected from the pool of responses that correctly identified an error in the code. Antonios answered:

Line 04: (x*x) must be replaced by ((x)*(x)) because there is problem with the priority of the operations

 

You can see the complete list of weekly winners and code challenges here.

What is the CC Weekly Code Challenge?
Each week, Circuit Cellar’s technical editors purposely insert an error in a snippet of code. It could be a semantic error, a syntax error, a design error, a spelling error, or another bug the editors slip in. You are challenged to find the error.Once the submission deadline passes, Circuit Cellar will randomly select one winner from the group of respondents who submit the correct answer.

Inspired? Want to try this week’s challenge? Get started!

Submission Deadline: The deadline for each week’s challenge is Sunday, 12 PM ESTRefer to the Rules, Terms & Conditions for information about eligibility and prizes.

Heinz Nickisch Wins the CC Code Challenge (Week 4)

We have a winner of last week’s CC Weekly Code Challenge, sponsored by IAR Systems! We posted a code snippet with an error and challenged the engineering community to find the mistake!

Congratulations to Heinz Nickisch of Bavaria, Germany, for winning the CC Weekly Code Challenge for Week 4! He’ll receive an IAR Kickstart kit.

Heinz’s correct answer was randomly selected from the pool of responses that correctly identified an error in the code. Heinz answered:

Line 37: BEGIN instead of BEING

You can see the complete list of weekly winners and code challenges here.

What is the CC Weekly Code Challenge?
Each week, Circuit Cellar’s technical editors purposely insert an error in a snippet of code. It could be a semantic error, a syntax error, a design error, a spelling error, or another bug the editors slip in. You are challenged to find the error.Once the submission deadline passes, Circuit Cellar will randomly select one winner from the group of respondents who submit the correct answer.

Inspired? Want to try this week’s challenge? Get started!

Submission Deadline: The deadline for each week’s challenge is Sunday, 12 PM ESTRefer to the Rules, Terms & Conditions for information about eligibility and prizes.

Chu Tin Teng Wins the CC Code Challenge (Week 3)

We have a winner of last week’s CC Weekly Code Challenge, sponsored by IAR Systems! We posted a code snippet with an error and challenged the engineering community to find mistake!

Congratulations to Chu Tin Teng of Fremont, CA, for winning the CC Weekly Code Challenge for Week 3! He’ll receive a CC T-Shirt and one-year digital subscription/renewal to Circuit Cellar.

Chu’s correct answer was randomly selected from the pool of responses that correctly identified an error in the code. Chu answered:

Line 7: string comparison should use cmp, instead of <=>. New line should read as “($aa cmp $ba) || ($an <=> $bn)”.

You can see the complete list of weekly winners and code challenges here.

What is the CC Weekly Code Challenge?
Each week, Circuit Cellar’s technical editors purposely insert an error in a snippet of code. It could be a semantic error, a syntax error, a design error, a spelling error, or another bug the editors slip in. You are challenged to find the error.Once the submission deadline passes, Circuit Cellar will randomly select one winner from the group of respondents who submit the correct answer.

Inspired? Want to try this week’s challenge? Get started!

Submission Deadline: The deadline for each week’s challenge is Sunday, 12 PM ESTRefer to the Rules, Terms & Conditions for information about eligibility and prizes.

Chris Austen Wins the CC Code Challenge (Week 2)

It’s Wednesday, which means we’re announcing the winner of last week’s CC Weekly Code Challenge, sponsored by IAR Systems! We posted a code snippet with an error and challenged the engineering community to find mistake!

Congratulations to Chris Austen of South Yorkshire, UK, for winning the CC Weekly Code Challenge for Week 2! He’ll receive a CC Gold issue archive on a USB drive.

Chris’s correct answer was randomly selected from the pool of responses that correctly identified an error in the code. Chris answered:

Line 5: ROT should be SWAP ROT for the given stack effect – though -ROT will work too.

The Code Challenge for Week 2

You can see the complete list of weekly winners and code challenges here.

What is the CC Weekly Code Challenge?
Each week, Circuit Cellar’s technical editors purposely insert an error in a snippet of code. It could be a semantic error, a syntax error, a design error, a spelling error, or another bug the editors slip in. You are challenged to find the error.Once the submission deadline passes, Circuit Cellar will randomly select one winner from the group of respondents who submit the correct answer.

Inspired? Want to try this week’s challenge? Get started!

Submission Deadline: The deadline for each week’s challenge is Sunday, 12 PM ESTRefer to the Rules, Terms & Conditions for information about eligibility and prizes.

CC Weekly Code Challenge Winner

It’s Wednesday, which means we’re announcing the winner of the most recent CC Weekly Code Challenge, sponsored by IAR Systems!

Congratulations to Peter Baston of Flintshire, UK, for winning the CC Weekly Code Challenge for Week 1! He’ll receive an IAR Kickstart: KSK-LPC4088-JL.

Peter’s correct answer was randomly selected from the pool of responses that correctly identified an error in the code. Peter answered Line 9: There should not be a “*” before argv[i].

You can see the complete list of weekly winners and code challenges here.

 

What is the CC Weekly Code Challenge?
Each week, Circuit Cellar’s technical editors purposely insert an error in a snippet of code. It could be a semantic error, a syntax error, a design error, a spelling error, or another bug the editors slip in. You are challenged to find the error.Once the submission deadline passes, Circuit Cellar will randomly select one winner from the group of respondents who submit the correct answer.

Inspired? Want to try this week’s challenge? Get started!

Submission Deadline: The deadline for each week’s challenge is Sunday, 12 PM ESTRefer to the Rules, Terms & Conditions for information about eligibility and prizes.

CC25 Is Now Available

Ready to take a look at the past, present, and future of embedded technology, microcomputer programming, and electrical engineering? CC25 is now available.

Check out the issue preview.

We achieved three main goals by putting together this issue. One, we properly documented the history of Circuit Cellar from its launch in 1988 as a bi-monthly magazine
about microcomputer applications to the present day. Two, we gathered immediately applicable tips and tricks from professional engineers about designing, programming, and completing electronics projects. Three, we recorded the thoughts of innovative engineers, academics, and industry leaders on the future of embedded technologies ranging from
rapid prototyping platforms to 8-bit chips to FPGAs.

The issue’s content is gathered in three main sections. Each section comprises essays, project information, and interviews. In the Past section, we feature essays on the early days of Circuit Cellar, the thoughts of long-time readers about their first MCU-based projects, and more. For instance, Circuit Cellar‘s founder Steve Ciarcia writes about his early projects and the magazine’s launch in 1988. Long-time editor/contributor Dave Tweed documents some of his favorite projects from the past 25 years.

The Present section features advice from working hardware and software engineers. Examples include a review of embedded security risks and design tips for ensuring system reliability. We also include short interviews with professionals about their preferred microcontrollers, current projects, and engineering-related interests.

The Future section features essays by innovators such as Adafruit Industries founder Limor Fried, ARM engineer Simon Ford, and University of Utah professor John Regehr on topics such as the future of DIY engineering, rapid prototyping, and small-RAM devices. The section also features two different sets of interviews. In one, corporate leaders such as Microchip Technology CEO Steve Sanghi and IAR Systems CEO Stefan Skarin speculate on the future of embedded technology. In the other, engineers such as Stephen Edwards (Columbia University) offer their thoughts about the technologies that will shape our future.

As you read the issue, ask yourself the same questions we asked our contributors: What’s your take on the history of embedded technology? What can you design and program today? What do you think about the future of embedded technology? Let us know.

Electrostatic Cleaning Robot Project

How do you clean a clean-energy generating system? With a microcontroller (and a few other parts, of course). An excellent example is US designer Scott Potter’s award-winning, Renesas RL78 microcontroller-based Electrostatic Cleaning Robot system that cleans heliostats (i.e., solar-tracking mirrors) used in solar energy-harvesting systems. Renesas and Circuit Cellar magazine announced this week at DevCon 2012 in Garden Grove, CA, that Potter’s design won First Prize in the RL78 Green Energy Challenge.

This image depicts two Electrostatic Cleaning Robots set up on two heliostats. (Source: S. Potter)

The nearby image depicts two Electrostatic Cleaning Robots set up vertically in order to clean the two heliostats in a horizontal left-to-right (and vice versa) fashion.

The Electrostatic Cleaning Robot in place to clean

Potter’s design can quickly clean heliostats in Concentrating Solar Power (CSP) plants. The heliostats must be clean in order to maximize steam production, which generates power.

The robot cleaner prototype

Built around an RL78 microcontroller, the Electrostatic Cleaning Robot provides a reliable cleaning solution that’s powered entirely by photovoltaic cells. The robot traverses the surface of the mirror and uses a high-voltage AC electric field to sweep away dust and debris.

Parts and circuitry inside the robot cleaner

Object oriented C++ software, developed with the IAR Embedded Workbench and the RL78 Demonstration Kit, controls the device.

IAR Embedded Workbench IDE

The RL78 microcontroller uses the following for system control:

• 20 Digital I/Os used as system control lines

• 1 ADC monitors solar cell voltage

• 1 Interval timer provides controller time tick

• Timer array unit: 4 timers capture the width of sensor pulses

• Watchdog timer for system reliability

• Low voltage detection for reliable operation in intermittent solar conditions

• RTC used in diagnostic logs

• 1 UART used for diagnostics

• Flash memory for storing diagnostic logs

The complete project (description, schematics, diagrams, and code) is now available on the Challenge website.

 

CC 25th Anniversary Issue: The Past, Present, and Future of Embedded Design

In celebration of Circuit Cellar’s 25th year of publishing electrical engineering articles, we’ll release a special edition magazine around the start of 2013. The issue’s theme will be the past, present, and future of embedded electronics. World-renowned engineers, innovators, academics, and corporate leaders will provide essays, interviews, and projects on embedded design-related topics such as mixed-signal designs, the future of 8-bit chips, rapid prototyping, FPGAs, graphical user interfaces, embedded security, and much more.

Here are some of the essay topics that will appear in the issue:

  • The history of Circuit Cellar — Steve Ciarcia (Founder, Circuit Cellar, Engineer)
  • Do small-RAM devices have a future? — by John Regehr (Professor, University of Utah)
  • A review of embedded security risks — by Patrick Schaumont (Professor, Virginia Tech)
  • The DIY electronics revolution — by Limor Fried (Founder, Adafruit Industries)
  • The future of rapid prototyping — by Simon Ford (ARM mbed, Engineer)
  • Robust design — by George Novacek (Engineer, Retired Aerospace Executive)
  • Twenty-five essential embedded system design principles — by Bob Japenga (Embedded Systems Engineer, Co-Founder, Microtools Inc.)
  • Mixed-signal designs: the 25 errors you’ll make at least once — by Robert Lacoste (Founder, Alciom; Engineer)
  • User interface tips for embedded designers — by Curt Twillinger (Engineer)
  • Thinking in terms of hardware platforms, not chips — by Clemens Valens (Engineer, Elektor)
  • The future of FPGAs — by Colin O’Flynn (Engineer)
  • The future of e-learning for engineers and programmers — by Marty Hauff (e-Learning Specialist, Altium)
  • And more!

Interviews

We’ll feature interviews with embedded industry leaders and forward-thinking embedded design engineers and programmers such as:

More Content

In addition to the essays and interviews listed above, the issue will also include:

  • PROJECTS will be available via QR codes
  • INFOGRAPHICS depicting tech-related likes, dislikes, and ideas of hundreds of engineers.
  • And a few surprises!

Who Gets It?

All Circuit Cellar subscribers will receive the 25th Anniversary issue. Additionally, the magazine will be available online and promoted by Circuit Cellar’s parent company, Elektor International Media.

Get Involved

Want to get involved? Sponsorship and advertising opportunities are still available. Find out more by contacting Peter Wostrel at Strategic Media Marketing at 978-281-7708 (ext. 100) or peter@smmarketing.us. Inquire about editorial opportunities by contacting the editorial department.

About Circuit Cellar

Steve Ciarcia launched Circuit Cellar magazine in 1988. From its beginning as “Ciarcia’s Circuit Cellar,” a popular, long-running column in BYTE magazine, Ciarcia leveraged his engineering knowledge and passion for writing about it by launching his own publication. Since then, tens of thousands of readers around the world have come to regard Circuit Cellar as the #1 source for need-to-know information about embedded electronics, design, and programming.

DIY Green Energy Design Projects

Ready to start a low-power or energy-monitoring microcontroller-based design project? You’re in luck. We’re featuring eight award-winning, green energy-related designs that will help get your creative juices flowing.

The projects listed below placed at the top of Renesas’s RL78 Green Energy Challenge.

Electrostatic Cleaning Robot: Solar tracking mirrors, called heliostats, are an integral part of Concentrating Solar Power (CSP) plants. They must be kept clean to help maximize the production of steam, which generates power. Using an RL78, the innovative Electrostatic Cleaning Robot provides a reliable cleaning solution that’s powered entirely by photovoltaic cells. The robot traverses the surface of the mirror and uses a high voltage AC electric field to sweep away dust and debris.

Parts and circuitry inside the robot cleaner

Cloud Electrofusion Machine: Using approximately 400 times less energy than commercial electrofusion machines, the Cloud Electrofusion Machine is designed for welding 0.5″ to 2″ polyethylene fittings. The RL78-controlled machine is designed to read a barcode on the fitting which determines fusion parameters and traceability. Along with the barcode data, the system logs GPS location to an SD card, if present, and transmits the data for each fusion to a cloud database for tracking purposes and quality control.

Inside the electrofusion machine (Source: M. Hamilton)

The Sun Chaser: A GPS Reference Station: The Sun Chaser is a well-designed, solar-based energy harvesting system that automatically recalculates the direction of a solar panel to ensure it is always facing the sun. Mounted on a rotating disc, the solar panel’s orientation is calculated using the registered GPS position. With an external compass, the internal accelerometer, a DC motor and stepper motor, you can determine the solar panel’s exact position. The system uses the Renesas RDKRL78G13 evaluation board running the Micrium µC/OS-III real-time kernel.

[Video: ]

Water Heater by Solar Concentration: This solar water heater is powered by the RL78 evaluation board and designed to deflect concentrated amounts of sunlight onto a water pipe for continual heating. The deflector, armed with a counterweight for easy tilting, automatically adjusts the angle of reflection for maximum solar energy using the lowest power consumption possible.

RL78-based solar water heater (Source: P. Berquin)

Air Quality Mapper: Want to make sure the air along your daily walking path is clean? The Air Quality Mapper is a portable device designed to track levels of CO2 and CO gasses for constructing “Smog Maps” to determine the healthiest routes. Constructed with an RDKRL78G13, the Mapper receives location data from its GPS module, takes readings of the CO2 and CO concentrations along a specific route and stores the data in an SD card. Using a PC, you can parse the SD card data, plot it, and upload it automatically to an online MySQL database that presents the data in a Google map.

Air quality mapper design (Source: R. Alvarez Torrico)

Wireless Remote Solar-Powered “Meteo Sensor”: You can easily measure meteorological parameters with the “Meteo Sensor.” The RL78 MCU-based design takes cyclical measurements of temperature, humidity, atmospheric pressure, and supply voltage, and shares them using digital radio transceivers. Receivers are configured for listening of incoming data on the same radio channel. It simplifies the way weather data is gathered and eases construction of local measurement networks while being optimized for low energy usage and long battery life.

The design takes cyclical measurements of temperature, humidity, atmospheric pressure, and supply voltage, and shares them using digital radio transceivers. (Source: G. Kaczmarek)

Portable Power Quality Meter: Monitoring electrical usage is becoming increasingly popular in modern homes. The Portable Power Quality Meter uses an RL78 MCU to read power factor, total harmonic distortion, line frequency, voltage, and electrical consumption information and stores the data for analysis.

The portable power quality meter uses an RL78 MCU to read power factor, total harmonic distortion, line frequency, voltage, and electrical consumption information and stores the data for analysis. (Source: A. Barbosa)

High-Altitude Low-Cost Experimental Glider (HALO): The “HALO” experimental glider project consists of three main parts. A weather balloon is the carrier section. A glider (the payload of the balloon) is the return section. A ground base section is used for communication and display telemetry data (not part of the contest project). Using the REFLEX flight simulator for testing, the glider has its own micro-GPS receiver, sensors and low-power MCU unit. It can take off, climb to pre-programmed altitude and return to a given coordinate.

High-altitude low-cost experimental glider (Source: J. Altenburg)

One-Time Passwords from Your Watch

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.

[Editor’s note: This article originally appeared in Circuit Cellar 262, May 2012.]

Patrick Schaumont writes the Embedded Security column for Circuit Cellar magazine. He is an Associate Professor in the Bradley Department of Electrical and Computer Engineering at Virginia Tech. Patrick works with his students on research projects in embedded security, covering hardware, firmware, and software.

PROJECT FILES

To download the code, go to ftp://ftp.circuitcellar.com/pub/Circuit_Cellar/2012/262.

RESOURCES

Google Authenticator, http://code.google.com/p/google-authenticator.

Initiative for Open Authentication (OATH), www.openauthentication.org.

Internet Engineering Task Force (IETF), www.ietf.org.

D. M’Raihi, et al, “TOTP: Time-Based One-Time Password Algorithm,” IETF RFC 6238, 2011.

—, “HOTP: An HMAC-Based One-Time Password Algorithm,” IETF RFC 4226, 2005.

OATH Toolkit, www.nongnu.org/oath-toolkit.

K. Schaffer, “Are Password Requirements Too Difficult?,” IEEE Computer Magazine, 2011.

S. Sengupta, “Logging in With a Touch or a Phrase (Anything but a Password),” New York Times, 2011.

SOURCES

IAR Embedded Workbench – IAR Systems

eZ430-Chronos Wireless development system and Code Composer Studio (CCStudio) IDE – Texas Instruments, Inc.