Teardown Of The Singaporean COVID-19 TraceTogether Token

June 25, 2020 by Maya Posch 63 Comments

A large part of fighting against the SARS-CoV-2 pandemic is the practice of contact tracing, where the whereabouts of an infected person can be traced and anyone who has been in contact with that person over the past days tested for COVID-19. While smartphone apps have been a popular choice for this kind of tracing, they come with a range of limitations, which is what the TraceTogether hardware token seeks to circumvent. Now [Sean “Xobs” Cross] has taken a look at the hardware that will be inside the token once it launches.

Recently, [Sean] along with [Andrew “bunnie” Huang] and a few others were asked by GovTech Singapore to review their TraceTogether hardware token proposal. At its core it’s similar to the Simmel contact tracing solution – on which both are also working – with contacts stored locally in the device, Bluetooth communication, and a runtime of a few months or longer on the non-rechargeable batteries.

The tracing protocol used is BlueTrace, which is an open application protocol aimed at digital contact tracing. It was developed by the Singaporean government, initially for use with their TraceTogether mobile app.

This smartphone app showed a number of issues. First is that Apple does not allow for iOS apps to use Bluetooth in the background, requiring the app to be active in the foreground to be useful. Apple has its own tracing protocol, but it does not cover the requirements for building a full contact graph, as [Andrew] covers in more detail. Finally, the app in general is not useful to those who do not have a recent (compatible) smartphone, or who do not have a smartphone at all.

A lot of the challenges in developing these devices lie in making them low-power, while still having the Bluetooth transceiver active often enough to be useful, as well as having enough space to store interactions and the temporary tokens that are used in the tracing protocol. As Simmel and the TraceTogether tokens become available over the coming months, it will be interesting to see how well these predictions worked out.

Creating A Custom ASIC With The First Open Source PDK

June 25, 2020 by Maya Posch 23 Comments

A process design kit (PDK) is a by now fairly standard part of any transformation of a new chip design into silicon. A PDK describes how a design maps to a foundry’s tools, which itself are described by a DRM, or design rule manual. The FOSSi foundation now reports on a new, open PDK project launched by Google and SkyWater Technology. Although the OpenPDK project has been around for a while, it is a closed and highly proprietary system, aimed at manufacturers and foundries.

The SkyWater Open Source PDK on Github is listed as a collaboration between Google and SkyWater Technology Foundry to provide a fully open source PDK and related sources. This so that one can create manufacturable designs at the SkyWater foundry, that target the 130 nm node. Open tools here should mean a far lower cost of entry than is usually the case.

Although a quite old process node at this point (~19 years), it should nevertheless still be quite useful for a range of applications, especially those that merge digital and analog circuitry. SkyWater lists their SKY130 node technology stack as:

Support for internal 1.8V with 5.0V I/Os (operable at 2.5V)
1 level of local interconnect
5 levels of metal
Inductor-capable
High sheet rho poly resistor
Optional MiM capacitors
Includes SONOS shrunken cell
Supports 10V regulated supply
HV extended-drain NMOS and PMOS

It should be noted that use of this open source PDK is deemed experimental at this point in time, and should not be used for any commercial or otherwise sensitive applications.

Header image: Peellden/ CC BY-SA 3.0

Ditching X86, Apple Starts An ARM Race

June 25, 2020 by Zoe Skyforest 160 Comments

At its annual World Wide Developer Conference, Apple dropped many jaws when announcing that their Mac line will be switching away from Intel processors before the year is out. Intel’s x86 architecture is the third to grace Apple’s desktop computer products, succeeding PowerPC and the Motorola 68000 family before it.

In its place will be Apple’s own custom silicon, based on 64-bit ARM architecture. Apple are by no means the first to try and bring ARM chips to bear for general purpose computing, but can they succeed where others have failed?

Continue reading “Ditching X86, Apple Starts An ARM Race” →

New Silq Programming Language Aims To Make Quantum Programming Easier

June 22, 2020 by Maya Posch 18 Comments

Fresh from ETH Zurich comes the new Silq programming language. They also have submitted a paper to the PLDI 2020 conference on why they feel that it is the best quantum programming language so far. Although it may be not common knowledge, the lack of usable general purpose quantum computers has not kept multiple teams from developing programming languages for such computer systems.

Microsoft’s Q# is a strong contender in this space, along with the older QCL language. The claims by the Silq team on exactly why their language is better appear to come down to it being ‘more high level’, and by supporting automatic (and safe) uncomputation. While the ‘high level’ aspect is suspect since Q# is most decidedly a high-level programming language, their uncomputation claim does at least have some merit.

Uncomputation is a concept in quantum programming, where one occasionally has to remove a few intermediate objects from the current state because they may cause quantum interference that would affect the resulting output. Normally, one would save the intermediate result to a register for this, then reset the state and continue. Which parts of the state to keep and what to uncompute is however not easily determined, as a quick glance at related answers over at the Quantum Computing StackExchange and Theoretical Computer Science might reveal.

The main question thus appears the validity of this claim about Silq being able to automatically determine what ‘garbage’ can be safely uncomputed, and what should be part of the quantum interference. We have all seen with languages like Java and C# how even with traditional computing something as simple as garbage collecting can go horribly wrong. Maybe we shouldn’t count our quantum chickens yet until this particular waveform has fully collapsed.

(Thanks to Qes)

Smartglove Helps Cyclists Be Seen

June 20, 2020 by Zoe Skyforest 25 Comments

Cyclists share the road with other vehicles, often leading to problems when drivers fail to see or respect the rider’s space. To try and alleviate these issues, [Matlek] built the Smartglove to help cyclists communicate their intentions to other road users.

The project consists of a glove fitted with an Arduino Nano 33 BLE sense, featuring Bluetooth and motion sensing on board. Combined with TinyML machine learning code, the Arduino is able to sense hand gestures from the rider. These gestures are then interpreted, and relevant messages displayed on an LED screen worn on the rider’s back. Flicking the wrist left and right flashes indicators that the user is about to change direction, while a rearward flick flashes a warning that the user is braking.

It’s a tidy way to integrate vehicle-style lighting into a simple interface for cycling. This has benefits, particularly at night, for allowing other road users to see a cyclist and understand their intentions on the road. Of course, if you really want to be noticed, this bike boombox could also be a big help. Video after the break. Continue reading “Smartglove Helps Cyclists Be Seen” →

This Week In Security: HaveIBeenPwned And Facebook Attack Their Customers

June 19, 2020 by Jonathan Bennett 27 Comments

We’re fans of haveibeenpwned.com around here, but a weird story came across my proverbial desk this week — [Troy Hunt] wrote a malicious SQL injection into one of their emails! That attack string was a simple ';--

Wait, doesn’t that look familiar? You remember the header on the haveibeenpwned web page? Yeah, it’s ';--have i been pwned?. It’s a clever in-joke about SQL injection that’s part of the company’s brand. An automated announcement was sent out to a company that happened to use the GLPI service desk software. That company, which shall not be named for reasons that are about to become obvious, was running a slightly out-of-date install of GLPI. That email generated an automated support ticket, which started out with the magic collection of symbols. When a tech self-assigned the ticket, the SQL injection bug was triggered, and their entire ticket database was wiped out. The story ends happily, thanks to a good backup, and the company learned a valuable lesson. Continue reading “This Week In Security: HaveIBeenPwned And Facebook Attack Their Customers” →

Metasurface Design Methods Can Make LED Light Act More Like Lasers

June 18, 2020 by Maya Posch 33 Comments

Light-emitting diodes (LEDs) are not exactly new technology, but their use over time has evolved from rather dim replacements of incandescent signal lights in control panels to today’s home lighting. Although LEDs have the reputation of being power-efficient, there is still a lot of efficiency to be gained.

UC Santa Barbara researchers [Jonathan Schuller] and his team found that a large number of the photons that are generated never make it out of the LED. This means that the power that was used to generate these photons was essentially wasted. Ideally one would be able to have every single photon successfully make it out of the LED to contribute to the task of illuminating things.

In their paper titled ‘Unidirectional luminescence from InGaN/GaN quantum-well metasurfaces‘ (pre-publication Arxiv version) they describe the problem of photon emission in LEDs. Photons are normally radiated in all directions, causing a ‘spray’ of photons that can be guided somewhat by the LED’s packaging and other parameters. The challenge was thus to start at the beginning, having the LED emit as many photons in one direction as possible.

Their solution was the use of a metasurface-based design, consisting out of gallium nitride (GaN) nanorods on a sapphire substrate. These were embedded with indium gallium nitride (InGaN) quantum wells which emit the actual photons. According to one of the researchers, the idea is based on subwavelength antenna arrays already used with coherent light sources like lasers.

With experiments showing the simulated improvements, it seems that this research may lead to even brighter, more efficient LEDs before long if these findings translate to mass production.

(Thanks, Qes)