Corona Warn App currently requires a Google or Apple smartphone to work.

The idea of this project is to implement a drop-in-replacement for the closed
source GAP protocol, providing to upstream (which is e.g, Corona Warn App aka
CWA) the same API as provided by Google or Apple, but not using the built-in
bluetooth hardware for sending/receiving bluetooth ENF Beacons. Instead, the
beacons shall be sent by bracelet-type devices. The middleend will have to
connect to this bracelet using bluetooth or some other wireless technique. and
provide current time and other services to the bracelet. The middleend will
include support to either download the contacts database from the bracelet and
do the mathing on-phone or upload the TEK keys from the cerntral servers to
bracelets upon sight, so the bracelets can do the mathcing themselves.

The bracelet itself shall in any case perform the generation and storing of
daily keys, calucation and sending of EN Beacons, as well as receiving and
(at least temporarily) storing EN Beacons sent by other devices. For most
bracelets, I expect storage size, battery life time, processing power and
display capabilities on the bracelet itself will usually not be sufficient for
14 days of storing received Exposure Notification Events, or calculating if an
exposure happened, or displaying the risk of infection.

In the end, it should be possible to port all software based on the GAP
protocol (e.g. Corona Warn App, but also other countries implementations)
towards upstream interface of this middleend, and various bracelets towards
downstream interface of the middleend.

This enables to use for upstream:
- Apple smartphones
- current Android smartphones with or without license for Google Framework and
  with or without hardware that cannot send or receive BLE ENF Beacons
- Windows, Linux, Raspberry Pi, PCs and Laptops that have a modified version of
  CWA up and running

And for the bracelet aka downstream, you should be able to use:
- fitness tracker bracelets, e.g. a hacked nRF device (until those devices
  include support for this middleend out of the box)
- open hardware evaluation kits for bluetooth
This shall be small device you can trust to securely store your keys and
provide Exposure Notification services.

According to GAP protocol, the bracelet is to generate and store one 'tek_i'
key every day. Only in case upstream needs to upload those keys (positive
corona test or similar circumstances), the middleend shall obtain them from the
bracelet,

Every (including the first) tek_i key is generated as if it was the beginning
of the current day:

[crypto]
> Temporary Exposure Key
> When setting up the device for exposure detection, the first Temporary Exposure Key is generated on
> the device and associated with an 'ENIntervalNumber' 'i', corresponding to the time from which the
> key is valid. That value is aligned with the 'TEKRollingPeriod' and is derived as follows:
> 'i' := round_down( 'ENIntervalNumber'(Time at Key Generation) / 'TEKRollingPeriod' ) * 'TEKRollingPeriod'
> The devices generate the 16-byte Temporary Exposure Key as follows:
> 'tek_i' := CRNG(16)
> The key is securely stored along with 'i' . At the end of every 'TEKRollingPeriod', a new key is generated.

'ENIntervalNumber' is round_down(the current unix time in seconds since the
epoch divided by 10 minutes resp. 600 seconds / 144 values per day), encoded as
an 32-bit unsigned little-endian value. 'TEKRollingPeriod' is 14 (days).

The bracelet should be able to have a rolling random bluetooth address changing
every 10 to 20 minutes, Exactly whenever this bluetooth address changes
(randomly generated once every 10 to 20 minutes, see
ExposureNotification-BluetoothSpecification1.2.pdf), the rolling proximity
identifier as well as the associated encrypted metadata must also be changed /
calculated based on todays tek_i and the current ENIntervalNumber,

As a bracelet usually does not have a suitable real-time-clock, the middleend
needs to provide the exact value of the current unix time in seconds since the
epoch (possibly using some kind of NTP?), and the bracelet needs to do
something like adjtime() to update its internal notion of the current time.
Otherwise an observer could possibly derive the bracelet owner from changes in
the bracelets internal time / connections to its owners CWA.

Further notes and thoughts:

Bracelet:

Lithium coin cells have special power considerations. You should use as litte
power as possible, and you should use that power for as shortly as possible.
Running an embedded CPU usually takes more power if more Mhz are used, so use
less MHz for your CPU. But there is a tradeoff: if there also is some
additional constant overhead, so you still may have to raise the CPU frequency
to reduce this power usage. Also reduced transmission power could be great to
increase battery life time as well as reduce the number of logged far distance
ENF contacts - with the trade-off that if this power is lower than on typical
smartphones, then users might be discernible (as long as Covid bracelets are
rare).

The bracelet should mimick Google (or at least Apple) device behavior, to make
it virtually undistinguishable from other devices, Specifically timing and
field strength of beacon transmission and frequency of changing the keys need
to be taken into account here. We need to measure the behavior of typical smart
phones and adjust to it, And we should hope that both Google and Apple
sanitized their implementation, to appropriately randomize timing within the
permitted ranges, and reduce field strength for Exposure Notification Beacons,
as here very low field strengths seem perfect for long life spans as well as
the intended purpose of tracing "nearby" contacts, and then we could do the
same,

Due to environmental reasons, the bracelets should be usable also for
after-covid. They should be either "dual purpose" devices (e,g. trustworhty /
open source and with decentraliced processing (if such should exist) fittness
trackers) with covid-support added, or the same trackers temporarily repurposed
for covid-tracking only (due to trust issues with your fittnes tracker
company), or general purpose open hardware (coin-cell fitted bluetooth
development kits equipped with general purpose sensors) that can be after
corona used for other purposes like open source fitness trackers. Another
option would be to use single purpose hardware (with no features besides
bluetooth and enough memory), and continue to use it after corona for exposure
notification of other contagious diseases (flu, measles, running nose etc.), if
there is enough people thinking this might be a good idea. Maybe this is a way
out of pandemic as well as endemic contagious diseases, a way out of
antibiotica crisis and so on.

Freshly activated bracelets could be handed out for free and used in public
events (restaurants, concerts, football games) in case you dont have CWA
installed or forgot your smartphone at home, It would be the your obligation to
pair it with your upstream and middleend and off-load. Or alternatively to hand
it back together with some paper containing the device ID and your address, for
later use in case of diagnosed covid cases.

Overall system design:
It should be possible to use one upstream device together with multiple
bracelets (e.g. for parents tracking covid-status of their children or
grandparents) as well as one bracelet with multiple devices (roaming from work
laptop to home PC for people like me who do not usually carry a smartphone, or
for holidays with smartphone instead of a home PC). The middleend should cater
for these needs / perform covid risk calculation based on multiple sources.

References:
[crypto] ExposureNotification-CryptographySpecificationv1.2.pdf