-
Mar 01 2019 
IoT Product Developers Need Freedom and Ecosystem Support
With product developers focusing more on IoT applications, the need for ecosystem support and professional tools to help them get their concepts to market is greater than ever.
Individual product developers and developer communities continue to be key drivers of IoT innovation, meaning large technology vendors leveraging these innovations into industry-transforming architectures need to maintain a delicate balance, allowing developers freedom to pursue their own paths, while providing them with tools to turn visions into reality.
“There is so much innovation coming from developer communities, but putting up a lot of corporate constructs around them would be constraining,” said Bob Merriman, director of strategic planning at Avnet. “Supporting them within the frame of an ecosystem is really important.”
The need for ecosystem support and professional tools to help product developers get their concepts to market is greater than ever, as suggested by the results of Avnet’s recent Product Developer Index survey, which collected the opinions of 1,190 of the combined 1.3 million members of the Hackster.io and Element14 developer communities.
Among those surveyed, 61 percent said IoT and sensors are the most important technologies they are currently working with, overshadowing in significance technology segments such as robotics and drones. Also, 26 percent of developers called IoT the most improved technology of 2018, giving IoT the edge even over the red-hot field of artificial intelligence, which finished second at 25 percent.
While even the most ardent IoT enthusiasts may be growing cautious about the notion of attaching sensors to anything and everything, Merriman said the survey results suggest sensor technology continues to be “one of the most underrated technologies in IoT.” “We’re not near the top of the mountain yet in terms of what can be done with them,” he said.
That potential has driven a boom in product developers starting up and targeting IoT in recent years, but it doesn’t take long for many of them to encounter the practical business and technology challenges that accompany their ambition.
Time and cost were mentioned by Avnet survey respondents as the biggest general challenges developers faced in moving from design phases to manufacturing. About 34 percent of developers surveyed said obtaining enough financing was a major challenge. Likely because of that more than 37 percent of survey respondents said they sought out partners to help them bring their products to market.
“They run into that age-old problem of startups — the ‘Death Valley Curve,’” Merriman said. “They sometimes don’t have enough money to fully realize their projects, but they can’t generate the revenue yet that could help them do that, and they’re stuck in between.”
That makes it especially important for Avnet and other large technology product firms to be ready to support developers from very early stages through later stages of getting to market, with tools such as design services, prototyping capabilities and product certification assistance. Some may even need help with technology selection, as 26 percent of those surveyed by Avnet said that identifying the best technology to use in their designs was a major challenge. At the latter end of the go-to-market spectrum, about 22 percent cited the ability to obtain product certification as a particular difficulty.
Aside from those business and operational concerns, security continues to be a major challenge for developers. Eighty-one percent of those surveyed said it is the biggest technological hurdle they face in IoT deployments.
On that issue, the results of Avnet’s survey echoed what similar studies have said. For example, an Evans Data survey from last summer found that more than two-thirds of developers working on IoT projects were addressing how to optimize security on their devices and applications. Their own pain may have caused them to prioritize security optimization, as 70 percent of the developers from that study indicated they already had been affected by a security breach.
It’s no surprise then to see companies like Avnet now adding more security support tools to their ecosystem offerings. At last week’s Consumer Electronics Show in Las Vegas, Avnet unveiled a developer starter kit for using Microsoft Azure Sphere to secure IoT devices and applications.
While IoT developers face many challenges even before they can put their products in front of customers, there are indications that with ecosystem support some things are getting easier. Fifty-eight percent of those surveyed by Avnet said the process of developing and testing prototypes has become a smoother one – 17 percent more said so last year. Developers also reported that other processes, such as identifying technology sources and scaling up production, also are on the upswing.
In many cases, such improvements would not have been realized without developers’ participation in strong ecosystems. “The ecosystem support is what separates the haves from the have-nots in this space,” Merriman said. “No one out there has everything they need to succeed all on their own.”
Source: https://www.iotworldtoday.com/2019/01/14/iot-product-developers-need-freedom-and-ecosystem-support/
-
Mar 01 2019 
Trusted Platform Modules: 8 Surprises for IoT Security
Trusted Platform Modules are poorly understood by many, well understood by few.
Built into billions of devices, a Trusted Platform Module (TPM) is usually a specialized chip on an endpoint’s motherboard that stores cryptographic keys on behalf of its host system for authentication and protection of the endpoint. Each TPM chip contains one or more unique key pairs, certified by the vendor, called endorsement keys (EKs), for validating the TPM’s authenticity. A TPM can also store platform “measurements” that identify software and firmware running on the platform. To stop the TPM from protecting the system, a hacker would have to interfere with it physically. In addition to their popularity on the PC and network side, TPMs will be architected into billions of Internet of Things devices.
Surprise 1: TPMs are passive, not active devices. They do not control anything on the host system they are embedded on.
A widespread misconception is that a trusted platform module somehow controls the system it’s a part of, but a TPM is 100 percent passive with respect to the rest of the system.
The trusted platform module is a self-contained component that has its own storage and processing capabilities, which it uses for protected operations on internal resources such as keys and measurements. These resources, however, are data that are given to the TPM, or that it is asked to generate.
Typically, boot code uses the TPM to store measurements of software running on the system, and applications use the TPM to protect the application’s keys and report measurements. These activities are all externally driven, not initiated by the TPM.
Surprise 2: A TPM is only useful when other things in the device take advantage of it.
The TPM is part of a broader security ecosystem that includes everything from the BIOS to motherboards to account passwords. To obtain value from the TPM, system designers must create systems that rely on the TPM’s internal resources. In traditional TPM implementations, software is “measured” before it is run in order to identify rogue software. The measurements are stored in the TPM, giving it second-hand awareness of “bad” software. The TPM will protect keys it holds, refusing access to rogue software that does not meet the expected measurements. For example, for solutions like Microsoft Bitlocker, an attacker booting to the wrong OS could not decrypt data on the hard drive. Similarly, a TPM might not allow a key to be used to authenticate a device to a bank, preventing an attacker from unauthorized account access.
With proper integration, a TPM can support the security of billions of future IoT devices that would otherwise be difficult to protect. By creating system dependencies on a TPM for devices like automotive electronic control units (ECU), system designers can make it much more difficult to swap out a system component without detection.
Surprise 3: A TPM doesn’t help much — if at all — with the heralded secure boot.
Secure boot is a hot topic. Upon startup, a device should run only the authorized code, not rogue software planted by a malicious actor. However, TPMs don’t provide secure boot. This occurs before the TPM comes into play. When a system powers on, early boot code (such as a UEFI BIOS) must decide which software will run next and which measurements are sent to the TPM. After the secure boot decisions are made, then the TPM can be used. The currently-running software can use the TPM to authenticate or decrypt the next piece of software before it loads, but this does not protect a system if an attacker can get at the early boot code.
The TPM can support a well-designed boot process (including “measured boot” or “trusted boot,” which we will discuss later), but the TPM has no impact on a secure boot.
Surprise 4: TPM has not been particularly successful considering how long it’s been available.
TPM has withstood significant scrutiny and is well established in the security community. Given TPM’s favorable reputation, its longevity (more than 20 years and counting) and the fact that TPMs have shipped in volume in PCs since 2005, it’s surprising how few people really know how to work with them. As a result — especially in the IoT realm — TPMs are not being tapped to their full potential. TPMs became a ubiquitous checkoff item on RFPs for PC-related projects and appear in billions of devices today, but most devices use TPMs minimally, or not at all.
The good news: TPM 2.0 is more flexible than the original TPM specification, allowing the newest TPMs to be applied to many embedded applications, including industrial sensors and smart home devices. Example: There is a TPM 2.0 profile for using TPM on limited-functionality ECUs for automotive applications. Now, designers and developers can more easily select granular TPM functions, whether for vehicles or a valve controller at a water utility.
Surprise 5: Leveraging TPMs is exceedingly difficult. They were not designed to be user-friendly… and they’re not.
It took the top companies in the PC industry — Compaq, HP, IBM, Intel, Microsoft and others — years to build the ecosystem needed to make implementation of TPMs for PCs feasible. These companies carved out the TPM space, driving updates to hardware, firmware and software and defining new protocols. The expectation (or at least hope) was that with this infrastructure, TPM would become an effective enabler, acting like an interstate highway for security. That is, they would provide a smooth, straight, easy way to get to the destination. Unfortunately, TPM turned out to be so complicated that even with this rich ecosystem, almost nobody built solutions to leverage it.
Surprise 6: TPMs aren’t cheap.
Keep in mind, TPMs are hardware. Then, remember they’re not just hardware. Implementing a TPM solution also entails software, the device’s physical design, re-architecture of the system and modifications to integrate with the broader infrastructure. Adding a TPM could increase the cost of a device by fifty cents or more. For many embedded applications, that added cost is a dealbreaker. For devices already being re-architected or that have high security requirements, like those used to operate and secure industrial sites or critical infrastructure, the incremental cost is more likely to be justifiable.
Surprise 7: If a TPM is only used as a secure repository for encryption keys, money is probably being wasted.
Despite having a range of capabilities, TPMs are often used solely to protect symmetric or asymmetric keys, but simpler hardware or software-based designs can often do that job just as well as a TPM. If your platform already has a TPM, by all means, use it for key protection, but if you have a TPM, why not take advantage of the TPM’s more powerful features such as measurement-based access control and remote attestation?
Surprise 8: To retrofit an existing system, a hardware TPM is a non-starter.
Forget about it. Here’s why: the TPM must be architected into the overall system from the beginning. It’s not a last-minute add-on to plug in once a device has been produced. It’s hardware, and the platform must physically accommodate it. Moreover, the TPM must be fully integrated into the boot process and security functions of the platform.
Firmware or software-based TPMs offer alternatives. They are typically less secure than hardware-based TPM, but they can more easily be integrated into your design.
Source: https://www.iotworldtoday.com/2019/02/07/trusted-platform-modules-8-surprises-for-iot-security/
-
Mar 01 2019 
Bosch: Why AI and IoT Demand a New Problem-Solving Approach
Bosch’s North American president sheds light on how artificial intelligence and the Internet of Things are changing how industrial companies innovate.
In the center of Bosch’s CES booth was the prototype of an autonomous electric shuttle with a slew of surprising features. Riders can open the door of the vehicle using a smartphone app known as Perfectly Keyless. Once in the vehicle, a passenger has access to a concierge service that can inform a passenger if, say, an upcoming flight has been canceled and which alternate flight they would prefer. The concept vehicle also was equipped with camera sensors that could detect if a rider is about to leave an object behind when exiting the shuttle. The same sensors can determine when the vehicle needs to have its interior cleaned.
Such experimental prototypes are important for an engineering-focused company like Bosch because of the feedback about the types of features the public, city officials and other demographic segments value. With the shuttle (pictured below), the company wanted to “paint the picture of what could be,” said Mike Mansuetti, president of Bosch North America, pictured above on the right. And from there, they can use feedback from such experiments to better understand what should be. Many AI- and IoT-enabled projects sound nice in the abstract, but can still fail to win the support of end users.
The emerging technologies such as AI and IoT offer “endless” possibilities, Mansuetti said
So it is important that engineers are working to help solve customers’ pain points rather than develop gee-whiz technology for its own sake. “We’re very focused on user experience,” Mansuetti said. In a Bosch context, that means both getting feedback from potential users about prototypes such as the e-shuttle, but also asking open-ended questions such as: “What is your biggest problem?”
When asking questions like that, the answers can be occasionally stupefying for the company’s engineers, Mansuetti said. For instance, city officials might say their municipality’s biggest challenge is crime, a high school dropout rate or high infant mortality, and then follow up with a question of their own: “How can you help us?”
But ultimately, such information can spur further brainstorming for the company’s engineers and executives, who can then investigate the role that, say, transportation might play in such matters. “It is just a mindset change in the organization,” Mansuetti said.
Technologies such as AI and IoT are helping drive closer collaborations across its four core divisions, which span mobility solutions, consumer goods, industrial technology and energy and building technology. “We are starting to see more of the work happening horizontally in the organization,” Mansuetti explained.
The prospect of autonomous shuttles becoming mainstream in the not-too-distant future led Bosch engineers to wonder how to handle potential problems that arise in such vehicles when no person is physically present to address them. “That’s where this idea around in-vehicle sensing came,” Mansuetti said. “When you think about transportation as a service now, or mobility as a service, what are all those things that could happen?” A passenger could leave a smartphone or wallet behind, step into a dirty vehicle or a physical confrontation could occur between two passengers in the vehicle. “When nobody’s there, then you just start thinking about these things.” And it is this thought process that led the company to develop prototype solutions for such challenges.
While the company is hoping to play a pivotal role in helping commercialize such autonomous vehicles, it will rely on partners to produce the end product. “The intent is really not to go into the shuttle business just like we would never probably enter into building a car,” Mansuetti said. “We are focused on electronics and technology: Why would we want to put the sheet metal together? That’s just not something that we want to do.”
In other words, that’s a problem the company has decided is not worth solving.
Source: https://www.iotworldtoday.com/2019/02/07/bosch-why-ai-and-iot-demand-a-new-problem-solving-approach/
-
Mar 01 2019 
Ericsson reveals vision for next-gen cellular IoT solutions
Ericsson is empowering service providers across multiple industries to address a larger part of the IoT market with the help of its newly introduced next-generation cellular solutions.
These solutions will help proliferation of the cellular IoT evolution in what Ericsson sees as four market segments: broadband IoT, industrial automation IoT, massive IoT, and critical IoT.
Among those, industrial automation IoT and broadband IoT are two segments that are new; the former will allow advanced industrial automation applications with the most demanding connectivity requirements, whereas the latter adopts mobile broadband capabilities for IoT and supports higher data rates and lower latencies than massive IoT.
In accordance with its vision,
Ericsson is launching enhanced functionalities for massive IoT and new solutions for Broadband IoT. The 100km extension of NB-IoT cell range is one example of massive IoT enhancement, which results from stretching the standards-based limit from about 40km to 100 km via software updates without changing the existing NB-IoT devices. This benefits the rural and remote areas, especially for agriculture, logistics and environment monitoring. The company has deployed NB-IoT data connections up to 100km with Telstra and DISH.
Last month, Ericsson partnered with Deutsche Telekom to conduct a joint innovation project wherein it successfully demonstrated a millimetre wave link with data transmission rate of 40Gbps. The live trial, which was organised at the Deutsche Telekom Service Centre in Athens, is a breakthrough moment in the evolution from today’s 10Gbps reality toward the 100Gbps future. It was arranged over a hop distance of 1.4 kilometres in the millimetre wave (E-band) spectrum, which included a technical setup consisting Ericsson’s latest mobile transport technology including Ericsson’s MINI-LINK 6352 microwave solution and Router 6000.
In November, the Swedish telecom giant was selected by DISH for radio access and core network for its Narrowband Internet of Things (NB-IoT) network scheduled for March 2020. Ericsson leveraged its global wireless radio expertise to complete the initial radio frequency (RF) design for DISH’s nationwide NB-IoT network earlier in 2018.
-
Mar 01 2019 
Study reveals laxness among automakers in terms of cybersecurity
An independent study conducted by Ponemon Institute found that 30% of the automotive companies do not have their own cybersecurity programme or a team. It also found that these companies do not even hire external organisations to secure the software used in their products.
Moreover, the survey shows that around 63% of all automotive firms are heedless when it comes to testing vulnerabilities. Less than half of software, hardware, and other technologies they develop remain untested.
Commissioned by Synopsys and SAE International, the study used a sampling frame of 15,900 IT security practitioners and engineers in the automotive sector, in which the final sample comprised of 593 surveys. In order to make sure that the responses provided are relevant, the Ponemon Institute chose only those respondents who were either involved in assessing or contributing to the security of automotive components in their organisation.
The Report
The report says: “The security professionals surveyed for our report indicated that the typical automotive organisation has only nine full-time employees in its product cybersecurity management program.” According to the report, 60% of all responders lack understanding and training on secure coding practices, which is the key reason behind all vulnerabilities in the automotive software, components and technology. Among the respondents, 50% said that the lack of quality assurance and testing procedures, 55% mentioned accidental coding errors, and 40% highlighted the use of insecure/outdated open source software components as the most common factors that lead to vulnerabilities in their technologies.
“Seventy-three percent of respondents surveyed in our report say they are very concerned about the cybersecurity posture of automotive technologies supplied by third parties. However, only 44% of respondents say their organisations impose cybersecurity requirements for products provided by upstream suppliers.”
Security vulnerabilities have been found most of the times as software has been added to vehicles. For instance: In April 2018, a Dutch cyber-security firm found that in-vehicle infotainment (IVI) systems used by some car models from the Volkswagen Group were vulnerable to remote hacking. And in October 2017, an electronics designer discovered a fault in the key fob system of several Subaru models. This security issue was refused by Subaru to patch when contacted and that could potentially be abused to hijack its customers’ cars.
Source: https://www.iottechnews.com/news/2019/feb/07/study-automakers-terms-cybersecurity/
