Articles / Privacy Law

1012 words

  • right-to-repair
  • uk-law
  • hardware-security
  • secure-element
  • consumer-protection
  • firmware

Why Your Phone Repair Needs a Paired Part, and Whether the Law Cares

Swap a fingerprint sensor or camera module between two identical phones and one of them may stop working properly, or start nagging you about an "unknown part". The hardware is the same. What differs is a record in the phone that says which part belongs to it.

This is called parts pairing. It has a genuine security reason, a less noble commercial side, and a murky legal position in the UK. I will take those in turn.

What "paired" means in practice

A paired part is one the phone has been told to expect. Usually that means a serial number, and sometimes a cryptographic identity, is recorded on the handset (or on a server) and checked at boot or when the part is used.

Parts that commonly get this treatment, depending on make and model:

  • biometric sensors (fingerprint, face unlock)
  • batteries, where the controller reports health and a serial number
  • displays, which carry calibration data such as colour and brightness tuning
  • cameras, which carry per-unit calibration

Behaviour varies a lot between vendors and software versions, and the policies have changed over time. Treat any specific claim about one model as something to check against that vendor's current repair documentation.

The genuine security argument

A biometric sensor is part of a trust chain. The sensor captures a fingerprint, passes it to a secure processor, and the secure processor decides whether to unlock. If anyone could fit a sensor they controlled, they could feed the secure processor a forged "match" and bypass the lock.

Pairing closes that hole. The sensor and the secure processor share a secret or exchange signed messages, so the phone only trusts a sensor it has enrolled. That is also why a repair shop cannot simply move a working sensor from a donor phone: the donor's sensor is enrolled to the donor.

Here is a toy version of the idea in Go. It is simplified: real systems keep keys in dedicated hardware and use more careful protocols.

package main

import (
	"bytes"
	"crypto/ed25519"
	"crypto/rand"
	"fmt"
)

// part stands in for a sensor holding a private key it never reveals.
type part struct {
	serial []byte
	key    ed25519.PrivateKey
}

func (p part) respond(challenge []byte) []byte {
	msg := append(append([]byte{}, p.serial...), challenge...)
	return ed25519.Sign(p.key, msg)
}

// enrolled is what the phone stored when the part was paired.
type enrolled struct {
	serial []byte
	pub    ed25519.PublicKey
}

func (e enrolled) trusts(p part) (bool, error) {
	challenge := make([]byte, 32)
	if _, err := rand.Read(challenge); err != nil {
		return false, err
	}
	msg := append(append([]byte{}, p.serial...), challenge...)
	sig := p.respond(challenge)
	return bytes.Equal(p.serial, e.serial) && ed25519.Verify(e.pub, msg, sig), nil
}

func newPart(serial string) (part, enrolled, error) {
	pub, priv, err := ed25519.GenerateKey(rand.Reader)
	if err != nil {
		return part{}, enrolled{}, err
	}
	s := []byte(serial)
	return part{s, priv}, enrolled{s, pub}, nil
}

func main() {
	original, record, err := newPart("SENSOR-0001")
	if err != nil {
		panic(err)
	}
	donor, _, err := newPart("SENSOR-0002")
	if err != nil {
		panic(err)
	}

	ok, _ := record.trusts(original)
	fmt.Println("original sensor trusted:", ok)
	ok, _ = record.trusts(donor)
	fmt.Println("donor sensor trusted:", ok)
}

The donor is a perfectly good sensor, made by the same factory. It fails only because the phone's record does not mention it.

Quick detour: why a challenge at all?

Hang on, why not just check the serial number? Because a serial is a label, not a secret. Anyone can copy a label onto another part. The random challenge forces the part to prove it holds a private key, and a fresh challenge each time stops a recording of an old answer being replayed.

Note that many real pairing schemes are weaker than this, and only compare serial numbers. That is fine for "is this the part I was told about" but proves little about whether the part is trustworthy.

Where it stops being about security

The same mechanism works for parts that have nothing to do with unlocking the phone. A battery has no business deciding whether you are the owner. Yet if the phone shows a warning or disables a health readout for an unrecognised battery, the check is gating on who supplied the part, not on safety.

The usual vendor answer is that unknown parts may be unsafe or poorly calibrated, and that is sometimes true. The usual repairer answer is that a perfectly good second-hand genuine part is being rejected, and that the fix is a vendor tool or a vendor server call that independents may not get access to.

Both can be right at once. Which one dominates depends on the part: a sensor feeding the secure processor is a strong case; a cosmetic warning on a battery is a weak one.

What UK law says

I am drawing a line here between what the law says and what I think. The law first.

  • Legislation: the Consumer Rights Act 2015 requires goods to be of satisfactory quality, fit for purpose and as described. It does not mention parts pairing, and it is about the original sale rather than later repairs.
  • Right to repair rules: the UK's 2020 right to repair rules cover certain appliances such as washing machines and fridges. As far as I am aware, smartphones are not within them; check the current legislation on legislation.gov.uk before relying on that.
  • Guidance and courts: I am not aware of a UK court decision settling whether pairing a part to a handset is unlawful in itself.

So the honest position is that there is no UK rule specifically saying "a phone must accept a third-party or swapped part". Whether a particular lock-out is a problem would turn on facts: what the vendor said at sale, whether a working function was removed by a later update, and the contract terms.

Two earlier posts on this blog cover the neighbouring ground: what happens when firmware disables a device after repair, and how the right to repair rules treat firmware locks. This post is about the mechanism, not a repeat of those.

My opinion, flagged as such

Pairing is defensible for components in the unlock path, and hard to defend for the rest. A reasonable middle ground is to let any part work, show a plain notice that it is unverified, and keep the strict enforcement for the secure-processor chain.

Some vendors have moved in that direction, and have made official calibration and repair tools more widely available, but policies change, so check the current position for your handset before you buy parts.

Practical checks before you repair

  1. Look up the vendor's own repair guide for your exact model; it will say whether parts need pairing or calibration.
  2. Ask the repairer whether they use a genuine part, whether it will be paired, and whether biometrics will still work afterwards.
  3. Keep the old part until you have tested everything, including unlock, camera and charging.
  4. Get the repair, and any part warnings you were given, in writing.

If a repair ends with a feature that used to work being disabled, that is worth raising with the repairer and, if needed, with Citizens Advice, with the facts of your case in hand.

← All articles