Help: Pseudo Device Address randomness generation

[adamfowleruk]

Some phones incorrectly rotate their BLe MAC address every few seconds. This causes device discovery routines to reconsider a device even though it may have only just been identified recently. The Pseudo Device Address is a method around this. The mechanism used to generate this address needs to be reliable on a wide range of phones - even when idle for many hours - and prevent a passing attacker from predicting future addresses based on just the current observable address. There are many methods - we're looking for suggestions that work across Android devices going back, ideally, to Android 5.0.

Background: https://vmware.github.io/herald/bluetooth/hardware

Ideal timeline: PR ready for merge mid Jan 2021 (v1.3 release of Herald for Android).

If more time is required that isn't a huge issue - just let us know how far you are by sending a PR with a note that the content isn't ready for merge yet. That gives us some way to see progress.

Acceptance Criteria

• Cannot predict the next Pseudo Device Address based on casual observation of a number of previous addresses (E.g. 4 - an hours worth), without knowing the seed value chosen
• Must provide at least 6 bytes of randomness (same chance of a clash as a BLe MAC address)
• Values chosen must have even distribution across the random values chosen (i.e. no 'hot spots' in random addresses chosen) so as to avoid clashes
• Must not block the operation of Herald or Android OS whilst waiting for entropy to be generated. Minimum 12 hours without either degradation in, or loss of, continuity as per the Fair Efficacy Formula formal testing with 10 devices (The Herald project team can carry out this testing for you) (Continuity requires at least one RSSI reading from an advertisement every 30 seconds)
• Android versions supported (and ideally tested): Back to Android 5.0. May accept a mix of approaches based on Android version detection in code.
• Must be tested to work on a range of actual devices and not just theorised based on API documentation. Java and Android API documentation can not necessarily be trusted as device manufacturers are free to diverge from it in their implementations.

Implementation guidance

• Implement in Java only
• Provide tests for all functions
• See herald.datatypes.RandomSource for existing ideas
• Submitted as a PR to this project that can be merged
• Be sure to add a 'Signed-off-by' line in all commits to your PR, and follow the CONTRIBUTING.md file

Cool prizes

We don't have much in the way of budget for prizes being an open source project. We will soon be getting a set of Herald laptop stickers so we'd be happy to send one of those on.

Naturally the usual GitHub contributions, Authors.md file mention, and bragging rights we be available, as will the knowledge that your contribution has helped many installations and projects worldwide.

[adamfowleruk]

A solution has been contributed by one of our own project developers now as part of #190.