Hackers can take over robotic arms performing your surgery

---

Researchers are table to hijack a medical telerobot, raising questions around the security of remote surgery. 

---

In a scenario that sounds straight out of a Hollywood thriller, researchers at the University of Washington have discovered a flaw in surgical robotic arms that allows them to be easily hacked. The experts were able to take control of a Raven II telerobot through a series of cyber attacks, thereby enabling them to change the speed of the arms of the robot and their orientation, making it impossible for the machines to carry out a procedure as directed.

The first successful telesurgery took place back in 2001 when a doctor in New York completed a gall bladder surgery of a patient 3,700 miles away in France, and since then, long-distance robotic surgery has taken off. Though robotic surgery has yet to become the industry standard, sales of medical robots are increasing by 20% each year. Meaning, vulnerabilities can certainly wreak havoc on operations should the proper security measures not be implemented.

In the case of Raven II, a remote operator uses two winglike arms to perform complex procedures where otherwise their hands might not be capable. While this experiment was performed in a controlled environment and not on the operating table, it’s apparent that more stringent security measures be taken. Raven II runs on a single PC, and communicates with a control console using a standard communications protocol known as Interoperable Telesurgery Protocol. But rather than take place over a secure private channel, commands are sent over public networks instead — and therein lies the potential risk.

For their study, the team performed various types of cyberattacks to see just how easily the arm could be disrupted. This included changing the commands sent by an operator, modifying signals and even completely taking over the robot. The researchers note that while their test applies only to Raven II, other surgical mechanisms that use similar teleoperation were likely also at risk.

“In hijacking attacks, a malicious entity causes the robot to completely ignore the intentions of a surgeon, and to instead perform some other, potentially harmful actions. Some possible attacks includes both temporary and permanent takeovers of the robot, and depending on the actions executed by the robot after being hijacked, these attacks can be either very discreet or very noticeable,” the team writes.

Since surgery requires the upmost precision, any minor glitch at a critical moment could prove to be deadly for a patient. Subsequently, researchers suggest a number of ways that telesurgery can be more secure, including encrypting data as it’s transferred from surgeon to robot, making the software more sensitive to errors and attempted data changes, and better monitoring of the network status before and during surgery.

“Some of these attacks could have easily been prevented by using well-established and readily-available security mechanisms, including encryption and authentication,” the researchers note.

It’s becoming increasingly clear that embedded system insecurity affects everyone, and not only can these effects of insecurity lead to sensitive financial and medical data theft, but in some cases, could even lead to greater harm or fatality. This is why CryptoAuthentication protection is so paramount. As Atmel resident security expert Bill Boldt explains, “Hardware protection beats software protection every time. That is because software is always subject to bugs, tampering and malware, just as these attacks are proving. Again and again and again.”

Want to learn more? Download the entire paper here.

This device lets you send encrypted messages using social networks

---

Project Cuckoo looks at our interactions with intercepted social networks and how alternative ways of communicating might change them.

---

A new project from one Berlin-based designer has set out to explore our interactions with intercepted social networks and how alternative ways of communicating might change them. Created by Jochen Maria Weber, Cuckoo is a device that uses social media as a means of private communication, and encrypts messages into randomly generated words, meanings and noise in order to scatter them over multiple networks simultaneously.

The idea was conceived back in 2011 after Icelandic politician and activist spokesperson Birgitta Jónsdóttir was notified by Twitter that it had been subpoenaed by the U.S. Department of Justice demanding information around all her tweets since November 2009.

“Heavy data collection, surveillance and control became normal and more important, increasingly legal on most internet communication platforms,”  Weber writes. “What if we used social networks but hiding our actual information? What if we could use their infrastructure without divulging privacy?”

With Cuckoo, each letter of an original message is immediately translated into complex forms of certain length forming new sentences, which are then posted to their respective social channel, next to randomly generated noise-sentences for distraction. The device also enables the encryption method to be changed with every new message. Any receiving unit following the respective social network accounts can filter and decrypt the important posts according to their encryption method and timestamp. Cuckoo combines these social networks to build a hidden one on top of their infrastructure, or as the designer puts it, “an egg in the others’ nests.”

The project was brought to life using the combination of Arduino Yún (ATmega32U4) and Temboo, along with Twitter, Skype and Tumblr APIs. Interested in learning more? Head over to its official page here. Meanwhile, be sure to check it out in action below.

Symmetric or asymmetric encryption, that is the question!

---

With the emergence of breaches and vulnerabilities, the need for hardware security has never been so paramount.

---

Confidentiality — one of the three foundational pillars of security, along with data integrity and authenticity — is created in a digital system via encryption and decryption. Encryption, of course, is scrambling a message in a certain way that only the intended party can descramble (i.e. decrypt) it and read it.

Throughout time, there have been a number of ways to encrypt and decrypt messages. Encryption was, in fact, used extensively by Julius Caesar, which led to the classic type of encryption aptly named, Caesar Cipher. The ancient Greeks beat Caesar to the punch, however. They used a device called a “Scytale,” which was a ribbon of leather or parchment that was wrapped around a rod of a diameter, of which only the sender and receiver were aware. The message was written on the wrapping and unfurled, then sent to the receiver who wrapped on on the rod of the same diameter in order to read it.

 

Modern Encryption

Modern encryption is based on published and vetted digital algorithms, such as Advanced Encryption System (AES), Secure Hashing Algorithms (SHA) and Elliptic Curve Cryptography (ECC), among many others. Given that these algorithms are public and known to everyone, the security must come from something else — that thing is a secret cryptographic “key.” This fundamental principal was articulated in the 19th century by  Auguste Kerckhoffs, a Dutch linguist, cryptographer and professor.

Kerckhoffs’ principle states that a cryptosystem should be secure even if everything about the system, except the key, is public knowledge. In other words: “The key to encryption is the key.” Note that Kirchoffs advocated what is now commonly referred to as “open-source” for the algorithm. Point being, this open-source method is more secure than trying to keep an algorithm itself obscured (sometimes called security by obscurity). Because the algorithms are known, managing the secret keys becomes the most important task of a cryptographer. Now, let’s look at that.

Symmetric and Asymmetric

Managing the key during the encryption-decryption process can be done in two basic ways: symmetric and asymmetric. Symmetric encryption uses the identical key to both encrypt and decrypt the data. Symmetric key algorithms are much faster computationally than asymmetric algorithms because the encryption process is less complicated. That’s because there is less processing involved.

The length of the key size directly determines the strength of the security. The longer the key, the more computation it will take to crack the code given a particular algorithm. The table below highlights the NIST guidelines for key length for different algorithms with equivalent security levels.  You can see that Elliptic Curve Cryptography (ECC) is a very compact algorithm. It has a small software footprint, low hardware implementation costs, low bandwidth requirements, and high device performance. That is one of the main reasons that ECC-based asymmetric cryptographic processes, such as ECDSA and  ECDH, are now being widely adopted. The strength of the sophisticated mathematics of ECC are a great ally of all three pillars of security, especially encryption.

Not only is symmetric faster and simpler; furthermore, a shorter key length can be used since the keys are never made public as is the case with asymmetric (i.e. Public Key Infrastructure) encryption. The challenge, of course, with symmetric is that the keys must be kept secret on both the sender and receiver sides. So, distributing a shared key to both sides is a major security risk. Mechanisms that maintain the secrecy of the shared key are paramount. One method for doing this is called Symmetric Session Key Exchange.

Asymmetric encryption is different in that it uses two mathematically related keys (a public and private key pair) for data encryption and decryption.  That takes away the security risk of key sharing. However, asymmetric requires much more processing power. Unlike the public key, the private key is never exposed. A message that is encrypted by using a public key can only be decrypted by applying the same algorithm and using the matching private key.

A message that is encrypted by using the private key can only be decrypted by using the matching public key. This is sort of like mathematical magic. Some of the  trade offs of symmetric and asymmetric are summarized below.

Symmetric

• Keys must be distributed in secret
• If a key is compromised the attacker can decrypt any message and/or impersonate one of the parties
• A network requires a large number of keys

Asymmetric

• Around 1000 times slower than symmetric
• Vulnerability to a “man-in-the-middle” attack, where the public key is intercepted and altered

Due to the time length associated with asymmetric, many real-world systems utilize combination of the two, where the secret key used in the symmetric encryption is itself encrypted with asymmetric encryption, and sent over an insecure channel.Then, the rest of the data is encrypted using symmetric encryption and sent over the insecure channel in the encrypted format. The receiver gets the asymmetrically encrypted key and decrypts it with his private key. Once the receiver has the symmetric key, it can be used to decrypt the symmetrically encrypted message. This is a type of key exchange.

Note that the man in the middle vulnerability can be easily addressed by employing the other pillar of security; namely authentication. Crypto engine devices with hardware key storage, most notably Atmel’s CrypotoAuthentication, have been designed specifically to address all three pillars of security in an easy to design and cost-effective manner. Ready to secure your next design? Get started here.

What is Ambient Security?

New technology and business buzzwords pop up constantly. Hardly a day goes by that you don’t see or hear words such as “cloud”, “IoT,” or “big data.” Let’s add one more to the list: “Ambient security.”

You’ll notice that big data, the cloud, and the IoT are all connected, literally and figuratively, and that is the point. Billions of things will communicate with each other without human intervention, mainly through the cloud, and will be used to collect phenomenal and unprecedented amounts of data that will ultimately change the universe.

As everything gets connected, each and every thing will also need to be secure. Without security, there is no way to trust that the things are who they say they are (i.e. authentic), and that the data has not been altered (i.e. data integrity). Due to the drive for bigger data, the cloud and smart communicating things are becoming ambient; and, because those things all require security, security itself is becoming ambient as well.  Fortunately, there is a method to easily spread strong security to all the nodes. (Hint: Atmel CryptoAuthentication.)

Big Data

At the moment, big data can be described as the use of inductive statistics and nonlinear system analysis on large amounts of low density (or quickly changing) data to determine correlations, regressions, and causal effects that were not previously possible. Increases in network size, bandwidth, and computing power are among the things enabling this data to get bigger — and this is happening at an exponential rate.

Big data became possible when the PC browser-based Internet first appeared, which paved the way for data being transferred around the globe. The sharp rise in data traffic was driven to a large extent by social media and companies’ desire to track purchasing and browsing habits to find ways to micro-target purchasers. This is the digitally-profiled world that Google, Amazon, Facebook, and other super-disruptors foisted upon us.  Like it or not, we are all being profiled, all the time, and are each complicit in that process. The march to bigger data continues despite the loss of privacy and is, in fact, driving a downfall in privacy. (Yet that’s a topic for another article.)

Biggering

The smart mobile revolution created the next stage of “biggering” (in the parlance of Dr. Seuss). Cell phones metamorphosed from a hybrid of old-fashioned wired telephones and walkie-talkies into full blown hand-held computers, thus releasing herds of new data into the wild. Big data hunters can thank Apple and the Android army for fueling that, with help from the artists formerly known as Nokia, Blackberry, and Motorola. Mobile data has been exploding due to its incredible convenience, utility, and of course, enjoyment factors. Now, the drive for bigger data is continuing beyond humans and into the autonomous realm with the advent of the Internet of Things (IoT).

Bigger Data, Little Things

IoT is clearly looking like the next big thing, which means the next big thing will be literally little things. Those things will be billions of communicating sensors spread across the world like smart dust — dust that talks to the “cloud.”

More Data

The availability of endless data and the capability to effectively process it is creating a snowball effect where big data companies want to collect more data about more things, ad infinitum. You can almost hear chanting in the background: “More data… more data… more data…”

More data means many more potential correlations, and thus more insight to help make profits and propel the missions of non-profit organizations, governments, and other institutions. Big data creates its own appetite, and the data to satisfy that growing appetite will derive from literally everywhere via sensors tied to the Internet. This has already started.

Sensors manufacture data. That is their sole purpose. But, they need a life support system including smarts (i.e. controllers) and communications (such as Wi-Fi, Bluetooth and others). There is one more critical part of that: Security.

No Trust? No IoT! 

There’s no way to create a useful communicating sensor network without node security. To put it a different way, the value of the IoT depends directly on whether those nodes can be trusted. No trust. No IoT.  Without security, the Internet of Things is just a toy.

What exactly is security? It can best be defined by using the three-pillar model, which (ironically) can be referred to as “C.I.A:” Confidentiality, Integrity and Authenticity.

CIA

Confidentiality is ensuring that no one can read the message except its intended receiver. This is typically accomplished through encryption and decryption, which hides the message from all parties but the sender and receiver.

Integrity, which is also known as data integrity, is assuring that the received message was not altered. This is done using cryptographic functions. For symmetric, this is typically done by hashing the data with a secret key and sending the resulting MAC with the data to the other side which does the same functions to create the MAC and compare. Sign-verify is the way that asymmetric mechanisms ensure integrity.

Authenticity refers to verification that the sender of a message is who they say they are — in other words, ensuring that the sender is real. Symmetric authentication mechanisms are usually done with a challenge (often a random number) that are sent to the other side, which is hashed with a secret key to create a MAC response, before getting sent back to run the same calculations. These are then compared to the response MACs from both sides.

(Sometimes people add non-repudiation to the list of pillars, which is preventing the sender from later denying that they sent the message in the first place.)

The pillars of security can be  implemented with devices such as Atmel CryptoAuthentication crypto engines with secure key storage. These tiny devices are designed to make it easy to add robust security to lots of little things – -and big things, too.

So, don’t ever lose sight of the fact that big data, little things and cloud-based IoT are not even possible without ambient security. Creating ambient security is what CryptoAuthentication is all about.

ECDH key exchange is practical magic

What if you and I want to exchange encrypted messages? It seems like something that will increasingly be desired given all the NSA/Snowden revelations and all the other snooping shenanigans. The joke going around is that the motto of the NSA is really “Yes We Scan,” which sort of sums it up.

Encryption is essentially scrambling a message so only the intended reader can see it after they unscramble it. By definition, scrambling and unscrambling are inverse (i.e. reversible) processes. Doing and undoing mathematical operations in a secret way that outside parties cannot understand or see is the basis of encryption/decryption.

Julius Caesar used encryption to communicate privately. The act of shifting the alphabet by a specific number of places is still called the Caesar cipher. Note that the number of places is kept secret and acts as the key. Before Caesar, the Spartans used a rod of a certain thickness that was wrapped with leather and written upon with the spaces not part of the message being filled with decoy letters so only someone with the right diameter rod could read the message. This was called a skytale. The rod thickness acts as the key.

A modern-day encryption key is a number that is used by an encryption algorithm, such as AES (Advanced Encryption Standard) and others, to encode a message so no one other than the intended reader can see it. Only the intended parties are supposed to have the secret key. The interaction between a key and the algorithm is of fundamental importance in cryptography of all types. That interaction is where the magic happens. An algorithm is simply the formula that tells the processor the exact, step-by-step mathematical functions to perform and the order of those functions. The algorithm is where the magical mathematical spells are kept, but those are not kept secret in modern practice. The key is used with the algorithm to create secrecy.

For example, the magic formula of the AES algorithm is a substitution-permutation network process, meaning that AES uses a series of mathematical operations done upon the message to be encrypted and the cryptographic key (crypto people call the unencrypted message “plaintext“). How that works is that the output of one round of calculations done on the plaintext is substituted by another block of bits and then the output of that is changed (i.e. permutated) by another block of bits and then it happens over and over, again and again. This round-after-round of operations changes the coded text in a very confused manor, which is the whole idea. Decryption is exactly as it sounds, simply reversing the entire process.

That description, although in actual fact very cursory, is probably TMI here, but the point is that highly sophisticated mathematical cryptographic algorithms that have been tested and proven to be difficult to attack are available to everyone. If a secret key is kept secret, the message processed with that algorithm will be secret from unintended parties. This is called Kerckhoffs’ principle and is worth remembering since it is the heart of modern cryptography. What it says is that you need both the mathematical magic and secret keys for strong cryptography.

Another way to look at is that the enemy can know the formula, but it does him or her no good unless they know the secret key. That is, by the way, why it is so darn important to keep the secret key secret. Getting the key is what many attackers try to do by using a wide variety of innovative attacks that typically take advantage of software bugs. So, the best way to keep the secret is to store the key in secure hardware that can protect if from attacks. Software storage of keys is just not as strong as hardware storage. Bugs are endemic, no matter how hard the coders try to eliminate them. Hardware key storage trumping software is another fundamental point worth remembering.

Alright, so now that we have a good algorithm (e.g. AES) and a secret key we can start encrypting and feel confident that we will obtain confidentiality.

Key Agreement

In order for encryption on the sender’s side and decryption on the receiver’s side, both sides must agree to have the same key. That agreement can happen in advance, but that is not practical in many situations. As a result, there needs to be a way to exchange the key during the session where the encrypted message is to be sent. Another powerful cryptographic algorithm will be used to do just that.

There is a process called ECDH key agreement, which is a way to send the secret key without either of the sides actually having to meet each other. ECDH uses a different type of algorithm from AES that is called “EC” to send the secret key from one side to the other. EC stands for elliptic curve, which literally refers to a curve described by an elliptic equation.   A certain set of elliptic curves (defined by the constants in the equation) have the property that given two points on the curve (P and Q) there is a third point, P+Q, on the curve that displays the properties of commutivity, associativity, identity, and inverses when applying elliptic curve point multiplication. Point-multiplication is the operation of successively adding a point along an elliptic curve to itself repeatedly. Just for fun the shape of such an elliptic curve is shown in the diagram.

The thing that makes this all work is that EC point-multiplication is doable, but the inverse operation is not doable. Cryptographers call this a one-way or trap door function. (Trap doors go only one way, see?)  In regular math, with simple algebra if you know the values of A and A times B you can find the value of B very easily.  With Elliptic curve point-multiply if you know A and A point-multiplied by B you cannot figure out what B is. That is the magic. That irreversibility and the fact that A point-multiplied by B is equal to B point-multiplied by A (i.e. commutative) are what makes this a superb encryption algorithm, especially for use in key exchange.

To best explain key agreement with ECDH, let’s say that everyone agrees in advance on a number called G. Now we will do some point-multiply math. Let’s call the sender’s private key PrivKeySend.  (Note that each party can be a sender or receiver, but for this purpose we will name one the sender and the other the receiver just to be different from using the typical Alice and Bob nomenclature used by most crpyto books.) Each private key has a mathematically related and unique public key that is calculated using the elliptic curve equation.  Uniqueness is another reason why elliptic curves are used. If we point-multiply the number G by PrivKeySend we get PubKeySend. Let’s do the same thing for the receiver who has a different private key called PrivKeyReceive and point-multiply that private key by the same number G to get the receiver’s public key called PubKeyReceive.   The sender and receiver can then exchange their public keys with each other on any network since the public keys do not need to be kept secret. Even an unsecured email is fine.

Now, the sender and receiver can make computations using their respective private keys (which they are securely hiding and will never share) and the public key from the other side. Here is where the commutative law of point-multiply will work its magic. The sender point-multiplies the public key from the other side by his or her stored private key.  This is equates to:

PubKeyReceive point-multiplied by PrivKeySend which = G point-multiplied by PrivKeyReceive point-multiplied by PrivKeySend

The receiver does the same thing using his or her private key and the public key just received. This equates to:

PubKeySend point-multiplied by PrivKeyReceive  = G point-multiplied by PrivKeySend point-multiplied by PrivKeyReceive.

Because point-multiply is commutative these equations have the same value!

And, the rabbit comes out of the hat: The sender and receiver now have the exact same value, which can now be used as the new encryption key for AES, in their possession. No one besides them can get it because they would need to have one of the private keys and they cannot get them. This calculated value can now be used by the AES algorithm to encrypt and decrypt messages. Pretty cool, isn’t it?

Below is a wonderful video explaining the modular mathematics and discrete logarithm problem that creates the one-way, trapdoor function used in Diffie-Hellman key exhange. (Oh yeah, the “DH” in ECDH stands for Diffie-Hellman who were two of the inventors of this process.)

Are you building out for secure devices?  Protect your design investments and prevent compromise of your products? Receive a FREE Atmel CryptoAuthentication™ development tool.

Video Diary: Atmel @ CES 2014

It’s day two of CES 2014! Atmel is showcasing a number of devices, technologies and platforms for MakerSpaces, garages and living rooms. Check out the videos below to see what we’ve been up to!

Atmel tech reps at CES 2014 talk microcontrollers (MCUs), autotmotive technology, Arduino, Makers, biometric security, encryption, key fobs, tablets, 3D printers and medical devices.

Atmel is at the heart of the DIY Maker community – powering nearly every desktop 3D printer and Arduino board on the market today, along with a number of wearable platforms and devices. In this video, we interview a wide range of personalities about the rapidly growing movement, including Atmel’s Reza Kazerounian, Matt Richardson of Make Magazine and Michael Shiloh of Arduino.

Atmel’s latest touch solutions explained at CES 2014.

Atmel’s Bob Martin, Manager, MCU Central Applications Group, talks about the evolution of CES over the years, with a specific emphasis on the DIY Maker community.

Atmel Community Manager, Sylvie Barak, welcomes you to 3D print your ideas at CES 2014. Tweet #AtmelCES and come on by MP25958.

An inside look at 3D printing with the Atmel-powered MakerBot Replicator 2 at CES 2014. Tweet #AtmelCES.

After a long day at CES 2014 this on/off (0/1?) demo was pretty addictive – providing hours of endless entertainment for our tired crew.

A closer look at Atmel’s ATECC108

Atmel recently expanded its CryptoAuthentication portfolio with the ATECC108 solution, an elliptical curve cryptography (ECC) product. As Atmel Product Marketing Manager Alex Dean notes, there are two basic encryption methods available on the security market today: symmetric and asymmetric key based algorithms.

“In the context of using cryptography for authentication, symmetric key encryption uses an identical key on both a host and its client, while asymmetric key encryption employs two related keys (public and private),” Dean told Bits & Pieces.

“Perhaps most importantly, asymmetric key encryption eliminates the security risk of key sharing, as the private key is never exposed. Essentially, a message that is signed using the private key can only be verified by applying the same algorithm via a matching public key.”

Symmetric key algorithms are significantly faster computationally than asymmetric algorithms, as the encryption process is less complicated. As such, symmetric key solutions like Atmel’s ATSHA204 are quite versatile for a wide variety of use cases, including mobile items (smartphones, tablets), medical devices, industrial automation and smart energy, as well as any application where host-client authentication is needed. In addition to its asymmetric key attributes, the ATECC108 also performs symmetric key algorithm and is backward compatible to ATSHA204.

So when is an asymmetric key solution most appropriate? According to Dean, a complex medical platform (static) can best illustrate the need for an asymmetric key approach – specifically when such a system does not share the same key with an accessory (dynamic).

“When it comes to medical care, doctors and nurses want to ensure an accessory connected to hospital equipment is legitimate and not a cheap knockoff clone which can potentially endanger the lives of patients under their care. We know static systems are stringently reviewed by the FDA – and a hardware modification to implement security often triggers a lengthy re-approval process. However, their accessories and attachments, such as probes or catheters, are typically manufactured for one-time use and therefore subject to a different and sometimes less stringent regulation,” he explained.

“So an asymmetric key solution such as Atmel’s ATECC108 is most appropriate here. It is not necessary to modify any hardware on the static system to implement a public key, which by definition does not have to be protected. Inserting an ATECC108 to the accessory to protect the private key needed for authentication does not necessarily trigger re-certification due to different regulations that regulate the dynamic system – especially when the modification could be considered administrative (such as authentication), rather than medical. In short, an asymmetric key approach enables a medical equipment manufacture to quickly modify a medical system to ensure a host will only function with a genuine OEM accessory or peripheral manufactured by an authorized third party supplier. Remember, software is quite easy to compromise, so you need to protect the private key in the accessory or peripheral with ironclad hardware like the ATECC108.”

Similarly, since the public key on the static system does not require protection, systems already deployed in the field can be easily retrofitted with such a key via a simple administrative software upgrade involving the host system – a strategy that neatly avoids a time consuming FDA re-certification for a static hospital platform.

“Plus, the ECC algorithm (used by ATECC108) is far more efficient than RSA, which requires 3,000 bits to accomplish what the ECC can do with 256 bits. The RSA is slower, because it has to process such a large key size. That is why we see the industry shifting towards an ECC approach,” added Dean.

Lastly, in addition to the traditional UDFN and SOIC packages, the ATECC108 also offers a three-lead contact package that does not require a PCB and can be laminated directly to an item.

Secure personalization service safeguards your IP

Written by Steve Jarmusz

Afraid of having your IP/firmware stolen?  Don’t want unauthorized accessories in the marketplace taking revenue that’s rightfully yours and potentially damaging your brand equity?  Security concerns are serious and worth addressing, but what if you don’t have the expertise in cryptography or infrastructure?

Well, one turnkey solution that does not require security expertise are Atmel ATSHA204 CryptoAuthentication™ ICs.  Atmel provides a personalization service to customers of CryptoAuthentication products. This personalization service (configuring the CryptoAuthentication device for a specific application) is performed at final package test. Before this service can be performed, Atmel solicits secrets from the customer while never knowing the value of those secrets. The secrets are received from the customer encrypted and stay encrypted until they are requested by the test program at final package test. Because of the transport key mechanism innate to the ATSHA204 silicon, these secrets are even encrypted at the probe tips while they are being placed into the secure memory of the ATSHA204.

How does Atmel protect the secrets solicited from customers? We use a SafeNet Hardware Security Module (HSM), which are ranked #1 in worldwide markets. HSMs provide the highest performing, most secure transaction security solutions for enterprise and government organizations. They are used in banking, military, and other government applications where information security is paramount.

SafeNet, Hardware Safety Module

Atmel sends customers that are going to use the Secure Personalization Service the public key of a RSA key pair that was generated and stored on the HSM. Atmel also provides a template that represents the CryptoAuthentications memory contents and an encryption utility. Once the customer fills in this template with their specific data, it is encrypted with an AES key generated by the encryption utility. After AES encryption, the AES key is encrypted with the public RSA key and then deleted.

The encryption utility subsequently packages the AES encrypted template with customer secrets, the encrypted AES key and various other non-encrypted data used for data integrity into a file that is sent to Atmel. This file then is placed on the HSM system at locations performing the final ATSHA204 package tests. When the tester has determined that the ATSHA204 has passed all functional and electrical tests, that file is sent into the HSM for decryption. It is here that the secrets are placed into the ATSHA204 device’s secure memory. Both device and the SafeNet HSM are tamper proof. If a physical attack or tamper is detected, all data contents are destroyed.

Using the ATSHA204 for Firmware IP Protection

By: Ronnie Thomas

Read almost any major newspaper and you will see companies world-wide that have lost money due to theft of their intellectual property in the form of proprietary software or embedded firmware. The Atmel ATSHA204 CryptoAuthentication device is a great product to protect intellectual property by providing an inexpensive solution to protect software. The ATSHA204 capabilities include challenge-response functionality, diversified key schemes, rolling keys, and other protections to thwart would-be thieves.

Multiple challenge-response pairs

 

In addition, there are other counter-hacker techniques that could be leveraged with the ATSHA204 IC to provide more software theft protection, including:

• Multiple challenge-response pairs

When you use multiple challenge-response pairs, the system will choose a set of challenge/response pairs based on some algorithm in the system code. This could be a function call to the c library rand() or a fibonchi lfsr. The number of challenge/response pairs are limited by the amount of space that a given system has to store the support code and challenge/response pairs. In addition, this scenario could be made more complex by offsetting the where the challenge and its corresponding response or held in memory (i.e. the challenge could be held in array 5, while the response could be held in array 23.

• Chaining challenge-responses

In the chaining Challenge Response Technique, each response from the ATSHA204 can be fed back out as the new challenge. At some point the response would be evaluated and checked that the authentication verified successfully. By not evaluating the response each time the system gets the response from the client, the chain could execute a specified number of rounds without triggering a negative effect. If a hacker were monitoring the bus and failed the authentication check, they would not know which challenge/response was invalid.

• Code Misdirection

Code misdirection is the addition of code in the equation that obfuscates to some degree the code path that is being executed, thereby making it harder for would-be hackers to clone a device.  A function pointer is declared, a check is done with in a local function. Once the answer is received the function pointer is set to null. This makes it harder to de-compile the source code and clone a device. Code misdirection could also be used to point to code that causes severe penalties if the response to a given challenge is incorrect, such as pointing to a infinite loop or code that does something destructive.

• Move the Challenge to TempKey

In this example technique, a challenge could be stored in a reserved 32-byte register. At some point much later, the MAC command could be ran on the stored challenge and the response then could be sent back to the system. In this way it is much harder to pair a given challenge to that response.

• Rolled Key Mechanism

Instead of using a “static” key in the authentication calculation, the rolled key function in the ATSHA204 adds security by changing the key value used in the calculation by combining some offset values and creating a new key. The offset value could be something meaningful like the serial number, time stamp, random number, etc.  This new key would permanently remove the original key. After the key has been changed, there is no way to recover the original key. Instead of the challenge and response being the main source of protection, the keys themselves become that protection.

These are just a few examples of techniques that could be used. The examples could be used in combination with one another or with some other technique not mentioned. The end result should be the same when these measures fail by either:

• Reducing functionality
• Making a device inoperable
• Sending error messages
• Blacklisting the device
• Having code do something unexpected or incorrect
• Some other creative approach

If you are interested in learning more about using the ATSHA204 CryptoAuthentication device to protect against these counter-hacker techniques, please contact one of our security experts at crypto@atmel.com.

4 Different Authentication Models—Which One is Right for You?

By: Rocendo Bracamontes

Atmel’s ATSHA204 CryptoAuthentication™ device  allows four different ways to perform symmetric cryptographic authentication on a system:

• Fixed Challenge Authentication
  • Fixed Challenge Authentication is an easy way to add security to a product without the expense of added hardware to the host, interactive testing, or extensive software development. With Fixed Challenge Authentication, the client requires an ATSHA204 device programmed with secret keys. The host is able to use any number of pre-calculated challenge/response pairs to validate the presence of a valid ATSHA204 on the client side.

• Random Challenge Authentication
  • Random Challenge Authentication improves on the Fixed Challenge method by adding a Random Changing Challenge to each request. This feature enables the system to defend against replay-style attacks.
  •  By adding an ATSHA204 device to the host, the system can generate a Random Challenge for the client on the fly. In addition, by generating the challenge internally with the host’s ATSHA204 device, the response is unknown to the system, allowing the use of an unsecured processor without the threat that an attacker will be able to learn system secrets. This dramatically limits the ability of an unauthorized device from producing the correct response.

• Unique Challenge Authentication
  • Unique Challenge Authentication improves on the Fixed Challenge by adding a Unique Challenge to each request. This authentication feature enables the system to defend against replay-style attacks.
  • By adding an ATSHA204 device to the host, the system can generate a challenge for the client on the fly. This allows a unique challenge to be sent for every validation request.

• Diversified Key Authentication
  • This method includes the unique serial number of each ATSHA204 as part of the Cryptographic Authentication calculation. Diversified Key Authentication enables the host to identify the specific accessory that is trying to authenticate with it. This approach also enables the use of access lists (black lists) by the system.

With so many different options of authentication models, you can select the approach that best fits your design’s requirements, keeping your valuable intellectual property (IP) safe from malicious attacks or cloning.  To learn more about designing with the ATSHA204, including some design tips and tricks, check out this white paper.  Also stay tuned for further deep dives into each these models in the weeks to come.