Apple Home Key is an NFC protocol used by select HomeKit certified locks to authenticate a user using a virtual key provisioned into their Apple device.
There are three main components to the standard:
- Network:
- HAP: Used to provision reader private keys, issuer keys, configure public keys of the devices that are given access to a particular Apple Home instance;
- NFC:
- Authentication: runs on the SE and is based on the Car Key protocol, with minor changes, such as lack of direct pairing (which is done via HAP instead), changes to the KDF influcenced by multi-reader environment and other;
- Attestation exchange: implemented via HCE and uses ISO18013 engagement and NFC data transfer.
Just like parent protocols, Home Key has following advantages:
- This protocol provides reader authentication, data encryption, forward secrecy;
- It allows to share keys*, although this functionality is not implemented;
- In theory, future locks could implement UWB-based access as it's supported by specification.
- Nonce - Single-use number;
- EC - Elliptic Curve;
- Endpoint - end device;
- Issuer - a party that's generating keys;
- If a key is mentioned without algorithm info, assume its
secp256r1
; - Copernicus - codename of the Home Key applet implementation;
- UnifiedAccess - type codename of Copernicus-based wallet passes.
For HAP/HomeKit part of the Home Key, refer to comprehensive overview done by @kupa22.
Previously this section contained examples of some requests with possible meaning for each of their parts. With new knowledge, previous assumptions have been deemed to be misleading, and thus have been removed.
HardwareFinish of the first lock added to your home installation influences the color of the lock art for the whole home.
Following finish variations were found in IOS system files:
Color | Art | Value | Notes |
---|---|---|---|
Black | 00 00 00 |
||
Gold | AA D6 EC |
||
Silver | E3 E3 E3 |
||
Tan | CE D5 DA |
The default color. If an unexisting color combo is chosen, this color will be selected as a fallback |
00
also has to be appended to color value
Credit to @kupa22 for finding rest of the key colors
ECP allows Home Keys to work via express mode and is required to be implemented by certified locks.
Full Home Key ECP frame looks like this
6a 02 cb 02 06 021100 deadbeefdeadbeef
Following characteristics can be noted:
- It belongs to the Access(
02
) reader group with a dedicated subtype HomeKey(06
); - It contains a single 3-byte TCI with a value of
02 11 00
, no other variations have been met. IOS file system contains multiple copies of a Home Key pass json with this TCI; - The final 8 bytes of an ECP Home Key frame contain reader group identifier, which allows IOS to differentiate between keys for different Home installations.
(NOTE) Actual reader identifier is 16 bytes long, first 8 bytes are the same for all locks in a single home, while the latter 8 are unique to each one. First 8 are used for ECP.
(BUG) If more than one Home Key is added to a device, ECP stops working correctly, as a device responds to any reader emitting Home Key ECP frame even if the reader identifier is not known to it.
(BUG) If you disable express mode for a single key while having multiple with enabled express mode, it won't appear on a screen when brought near to a reader. Disabling express mode for all home keys fixes this issue.
Home Key uses two application identifiers:
- Home Key Primary:
A0000008580101
. Used for authentication. Implemented on the SE; - Home Key Configuration:
A0000008580102
. Used for attestation exchange. Implemented via HCE. Can only be selected after a successful STANDARD authentication with a following EXCHANGE and CONTROL FLOW commands.
In most situations a reader will only use the Primary applet.
Configuration applet will be selected only if a new device has been invited and a key data hasn't been provisioned into a lock prior to that;
Invitation is attested by the HAP pairing key of the person whom the device belongs to.
Command name | CLA | INS | P1 | P2 | DATA | LE | Response Data | Notes |
---|---|---|---|---|---|---|---|---|
SELECT USER APPLET | 00 |
A4 |
04 |
00 |
Home Key AID | 00 |
BER-TLV encoded data | |
FAST (AUTH0) | 80 |
80 |
FLAGS | TYPE | BER-TLV encoded data | 00 |
BER-TLV encoded data | Data format described below |
STANDARD (AUTH1) | 80 |
81 |
00 |
00 |
BER-TLV encoded data | Encrypted BER-TLV encoded data | Data format described below | |
EXCHANGE | 84 |
c9 |
00 |
00 |
Encrypted BER-TLV encoded data | Optional Encrypted BER-TLV encoded data | Data format described below | |
CONTROL FLOW | 80 |
3c |
STEP | INFO | None | None | No data, used purely for UX | |
SELECT CONFIGURATION APPLET | 00 |
a4 |
04 |
00 |
Home Key Configuration AID | 00 |
None | |
ENVELOPE | 00 |
c3 |
00 |
FRMT | BER-TLV with nested NDEF or CBOR with encrypted data | 00 |
BER-TLV with nested NDEF or CBOR with encrypted data | Data format described below |
GET RESPONSE | 00 |
c0 |
00 |
00 |
None | XX |
CBOR with encrypted data | LE is length of data expected in response. Response data format as the one requested in ENVELOPE |
Commands are executed in a following sequence:
- SELECT USER APPLET:
Reader transmits Home Key AID; Device responds with a version list TLV; Reader has to verify that there is a protocol version match between a list provided by a device and itself; - FAST (AUTH0):
Reader transmits required protocol version, transaction nonce, ephemeral publicsecp256r1
key, and its identifier;
Device responds with an authentication cryptogram and its own ephemeral publicsecp256r1
key;
Reader tries to verify that cryptogram was generated by a known device with a aforementioned encryption key;
A) If cryptograms match and there is no data to synchronize, authentication is confirmed and session is completed;
B) If there's a cryptogram mismatch or there is data to synchronize, we continue the command flow; - STANDARD (AUTH1):
Reader combines keys, nonces, other data exchanged during the transaction and signs it using its own private key; A device verifies that a signature is valid, and returns an encrypted payload containing signature of the transaction data using the device key; Common keys are established during this step to be used in FAST command in next communications. - EXCHANGE:
Using the established encrypted channel, reader can request a switch to a configuration applet, by providing a shared secret to be used during that operation.
In cases when a reader does not recognize the device, the communication continues further with configuration.
- CONTROL FLOW:
Used in between other commands to communicate transaction state to the device. This command is reponsible for UX, such as:
- Success checkmark;
- Failure exclamation mark;
- Error messages;
- Notify about a switch to configuration applet;
- SELECT CONFIGURATION APPLET:
Reader transmits Home Key Configuration AID. Device responds positively without any data; Re-selection is done because the device has to switch routing from the SE to HCE for attestation transfer. - ENVELOPE:
Reader transmits BER-TLV-encoded data with nested CBOR or NDEF messages.
First ENVELOPE command and response pair mimics ISO18013 NFC handover with NDEF.
Following command-response pairs mimic CBOR data transfer with nested encrypted data. Data format is the same as in ISO18013.
Useful payload part contains device'ssecp256r1
public key used by Home Key, attested by the publiced25519
HAP key of device owner.
- GET RESPONSE:
If a response to
ENVELOPE
orGET RESPONSE
had an sw6100
, reader uses this command to request additional response parts.
Alternative overview of the NFC transaction flow can be seen here.
CLA | INS | P1 | P2 | DATA | LE |
---|---|---|---|---|---|
00 |
A4 |
04 |
00 |
A0000008580101 |
00 |
DATA | SW1 | SW2 |
---|---|---|
BER-TLV data, refer to format | 90 |
00 |
Any response rather than 9000
means that applet is not available
Name | Tag | Length | Example | Notes |
---|---|---|---|---|
Supported versions | 5c |
2*n | 02000100 |
First byte is major version, second is minor |
Currently only versions 0100
and 0200
aka 1.0 and 2.0 are known
5c[04]:
02000100 # Supports version 2.0, and version 1.0
CLA | INS | P1 | P2 | DATA | LE |
---|---|---|---|---|---|
80 |
80 |
FLAGS | 00 |
BER-TLV data, refer to format | None |
FLAG and TYPE parameters seem to correlate with overall transaction length;
Flag:
00
if intending to use STANDARD command (no cryptogram will be generated in response);01
if trying to using FAST command only (still can continue with STANDARD if fail).
Name | Tag | Length | Example | Notes |
---|---|---|---|---|
Selected protocol version | 5c |
2 | 0200 |
First byte is major version, second is minor |
Reader ephemeral public key | 87 |
65 | 04 ... |
Contains an uncompressed secp256r1 public key |
Transaction nonce | 4c |
16 | ... | A random number used to verify that responses are generated during this session |
Reader identifier | 4d |
16 | ... | First 8 bytes is reader group, last 8 are unique to the reader |
DATA | SW1 | SW2 |
---|---|---|
BER-TLV data, refer to format | 90 |
00 |
Status other than 9000
cannot be encountered
Name | Tag | Length | Example | Notes |
---|---|---|---|---|
Device ephemeral public key | 86 |
65 | 04 ... |
Uncompressed secp256r1 public key |
Authentication cryptogram | 9d |
16 | ... | Optional, returned only if p1 is 01 |
86[41]:
046e197441b017a6452dfe33a3645860c09a7fb34f3e84c9d6a834c737fe4e4185b37cccc2004b9cb08f837b0920d42c59ab1ce403a95cefdfe221120175f82218
9d[10]:
7656a6256aee6f9bdc55ed45d96026a3
In order to guarantee privacy due to lack of reader authentication in FAST command, endpoint does not return identifyable data as-is. To find out if there's a cryptogram match, a reader has to iterate over all possible enrolled device combinations;
For a check to be successful, following data about the endpoint should be already present:
- Persistent key, generated during last successful STANDARD session with this reader identifier and endpoint combination;
- Endpoint public key;
Cryptogram is calculated using the HKDF SHA256 with 64 byte length, null salt, and custom shared info. Persistent key is used to derive the final result:
Shared info is built using the following data, in the same order as presented:
Name | Length | Example | Notes |
---|---|---|---|
Reader public key x component | 32 | ... | |
Fast authentication context constant | 12 | 566f6c6174696c6546617374 |
Encoded constant value VolatileFast |
Reader identifier | 16 | ... | |
Interface distinction flag constant | 1 | 5e |
|
Copy of protocol versions TLV tag returned by device on SELECT | 2 * (n * 2) | 5c0402000100 |
Was this done to protect against MITM and/or downgrade attacks? |
Copy of version TLV tag with the currently selected version | 4 | 5c020200 |
Only V2 of the Copernicus protocol is officially supported by HomeKey |
Reader ephemeral public key x component | 32 | ... | |
Transaction nonce | 16 | ... | |
Transaction flags | 2 | 0101 |
Preferred digital key flow + transaction type |
Endpoint ephemeral public key x component | 32 | ... |
Following python code provides an example of cryptogram generation:
key_size = 16
hkdf = HKDF(
algorithm=hashes.SHA256(),
length=key_size * 4,
salt=None,
info=info,
).derive(k_persistent)
kcmac = hkdf[: key_size * 1]
kenc = hkdf[key_size * 1 : key_size * 2]
kmac = hkdf[key_size * 2 : key_size * 3]
krmac = hkdf[key_size * 3 :]
calculated_cryptogram = kcmac
CLA | INS | P1 | P2 | DATA | LE |
---|---|---|---|---|---|
80 |
81 |
00 |
00 |
BER-TLV data, refer to format | None |
Name | Tag | Length | Example | Notes |
---|---|---|---|---|
Signature over shared info in point form | 9e |
64 |
9e[40]:
57a071cfeeff242878c68ef02fc430fe59cbf56741a1cadfcb0b23f962723d7321b67ab65015d50688edd17e7e658f4f6547b79bcbf9024a3bf701c216256050
DATA | SW1 | SW2 |
---|---|---|
BER-TLV encrypted data, refer to format | 90 |
00 |
Name | Tag | Length | Example | Notes |
---|---|---|---|---|
Device Signature over shared info in point form | 9e |
64 | ||
Device identifier | 4e |
6 |
During the STANDARD command, reader generates a signature over commonly known data in order to prove to the endpoint that it's safe to talk to, thus protecting against malicious readers. The device, in turn, generates its own signature, in order to prove itself to the reader.
Authentication hash uses the following components for input material, in the same order as presented:
Name | Tag | Length | Example | Notes |
---|---|---|---|---|
Reader identifier | 4d |
16 | ... | First 8 bytes is reader group, last 8 are unique to the reader |
Endpoint ephemeral public key x component | 86 |
32 | ... | |
Reader ephemeral public key x component | 87 |
32 | ... | |
Transaction nonce | 4c |
16 | ... | A random number used to verify that responses are generated during this session |
Reader context constant | 9c |
4 | 415d9569 |
Used only when generating proof by the reader |
Endpoint context constant | 9c |
4 | 4e887b4c |
Used only when verifying response of an endpoint |
This data is then signed using the ECDSA, and the resulting signature in point form is then used.
Following python code provides an example of signature generation:
signature = reader_private_key.sign(
authentication_hash_input, ec.ECDSA(hashes.SHA256())
)
x, y = decode_dss_signature(signature)
signature_point_form = bytes([*x.to_bytes(32, "big"), *y.to_bytes(32, "big")])
Following python code provides an example of signature verification:
try:
endpoint_public_key.verify(
signature, verification_hash_input, ec.ECDSA(hashes.SHA256())
)
except InvalidSignature as e:
pass
Starting from response of STANDARD command and onward, excluding OP CONTROL FLOW, a secure channel is used for communication. This means that both commands and responses will be encrypted.
Explaining the implementation could require a fully separate document itself, so it's omitted.
Instead, you're invited to take a look at session key deriviation code and at a digital key secure session implementation itself;
CLA | INS | P1 | P2 | DATA | LE |
---|---|---|---|---|---|
84 |
c9 |
00 |
00 |
BER-TLV encrypted data, refer to format | None |
Name | Tag | Length | Example | Notes |
---|---|---|---|---|
Constant zero | N/A | 1 | 00 |
Not a TLV tag |
Attestation exchange common secret | 8e |
34 | c020 ... |
A nested TLV tag with 32 bytes of random data |
CLA | INS | P1 | P2 | DATA | LE |
---|---|---|---|---|---|
80 |
3c |
STATUS | STEP | None | None |
SUCCESS is a flag that indicates transaction status:
00
- Failure;01
- Success (Checkmark will appear);40
- Need to switch to HCE applet for attestation exchange.
STEP is a second flag:
00
- Failure or success in normal circumstances;a0
- Need to switch to HCE applet for attestation exchange.
DATA | SW1 | SW2 |
---|---|---|
None | 90 |
00 |
CLA | INS | P1 | P2 | DATA | LE |
---|---|---|---|---|---|
00 |
A4 |
04 |
00 |
a0000008580102 |
00 |
DATA | SW1 | SW2 |
---|---|---|
None | 90 |
00 |
Any response rather than 9000
means that applet is not available.
This applet is only selectable after EXCHAGNE + CONTROL FLOW (need attestation) commands have been successfully used.
otherwise the device will present an error and stop NFC communication.
CLA | INS | P1 | P2 | DATA | LE |
---|---|---|---|---|---|
00 |
c3 |
00 |
FRMT | BER-TLV-encoded data with nested NDEF or CBOR | 00 |
FRMT real meaning is unknown, but according to observations it means the following:
01
NDEF nfc handover message in command and response (first command-response pair only);00
CBOR message in command in response (other command-response pairs).
DATA | SW1 | SW2 |
---|---|---|
BER-TLV-encoded data with nested NDEF or CBOR | XX |
XX |
Status words:
SW1 | SW2 | Notes |
---|---|---|
90 |
00 |
Data returned in full |
61 |
XX |
More data can be requested (00 also valid value meaning that more than 255 bytes left) |
Starting from ENVELOPE 00
, ISO18013 secure context is used during communication.
ISO18013 secure context does not encrypt the outer payload, but only the inner data inside of TLV tag.
Describing the implementation in full is out of scope of this document. Instead, you're invited to take a look at session key deriviation code and at a ISO18013 secure session implementation itself;
CLA | INS | P1 | P2 | DATA | LE |
---|---|---|---|---|---|
00 |
c0 |
00 |
00 |
None | XX |
LE should be equal to the value returned in the previous response to ENVELOPE
or GET RESPONSE
;
DATA | SW1 | SW2 |
---|---|---|
TLV-encoded data/part | XX |
XX |
Status words:
SW1 | SW2 | Notes |
---|---|---|
90 |
00 |
Data returned in full |
61 |
XX |
More data can be requested (00 also valid value meaning that more than 255 bytes left) |
After a full attestation package has been retrieved using ENVELOPE + GET RESPONSE, it has to be verified.
Verification process mimics the ISO18013 claim verification process. The attestation package itself is signed by the issuer key known to a lock, issuer identifier is located in unprotected headers.
Following python code provides an example of attestation verification:
attestation_package_cbor = cbor2.loads(attestation_package)
issuer_signed_cbor = attestation_package_cbor["documents"][0]["issuerSigned"]["issuerAuth"]
protected_headers, unprotected_headers, data, signature = issuer_signed_cbor
issuer_id = unprotected_headers[4]
data_cbor = cbor2.loads(cbor2.loads(data).value)
device_key_info = data_cbor["deviceKeyInfo"]["deviceKey"]
device_public_key_x, device_public_key_y = (
device_key_info[-2],
device_key_info[-3],
)
device_public_key_bytes = (
bytes.fromhex("04") + device_public_key_x + device_public_key_y
)
issuer = find_issuer_by_id(issuers, id=issuer_id)
if issuer is None:
raise ProtocolError(f"Could not find issuer {issuer_id}")
public_key = ed25519.Ed25519PublicKey.from_public_bytes(issuer.public_key)
data_to_sign = cbor2.dumps([COSE_CONTEXT, protected_headers, COSE_AAD, data])
try:
public_key.verify(signature, data_to_sign)
except InvalidSignature:
pass
Unlike with Car Keys, where invited keys are attested by the key of a car owner, each Home Key is attested by the HAP (AKA issuer) keys of each particular person.
This has following advantages:
- People may be removed from Apple Home at will, as it wouldn't break the attestation chain for everyone else (only the HAP-issuer key of removed person will be removed);
- It allows for a lock to support much more enrolled devices, as the lock really only needs to permanently store issuer keys, and a single one can attest multiple devices at a time (phone + watch).
Although in reality the lock still stores some amount of credentials locally (current locks report up to 16), as attestation exchange takes much longer than FAST auth (0.2sec vs 1sec);
But there are also disadvantages:
- Home Key protocol, unlike Car Key protocol, does not support "free-for-all" sharing natively, as it assumes that each key is bound to a particular HAP key, which automatically requires someone to be present in your Apple Home.
For people who still expect sharing to happen, not all hope is lost, as:
- Standard seems to have provisions for adding "Issuer keys" into a lock independently of HAP, but it is not known if it is actually implemented by the existing locks.
- Key sharing may be implemented via stub/fake/invisible HomeKit users, where an issuer key of a fake user will be used to attest a key of an invited person;
Only the time will tell if they are going to do any of that;
During the tests, it has been found out that a single device can store up to 16 persistent keys used for FAST authentication.
The keys are overwritten in a FIFO/Cyclic fashion, with the oldest unused one removed the first.
Even with this limitation, the possible amount of locks in a single household is virtually unlimited, as your device will still fallback to a STANDARD authentication or even an attestation exchange if needed.
Configuration applet, utilized for attestation package retrieval, is believed to be implemented via HCE. The reasons for that are the following:
- It doesn't work in power reserve mode, with NFC communication hanging on reselection;
- The same attestation package transferred during communication can be found in the .pkpass file of the key inside of the normal file system;
That would explain the need for additional applet reselection, as this is one of the ways of returning control to the OS in order to give it an ability to read the package file and send it via NFC.
Also, storing a static 0.6-1kb package inside of the highly limited (1mb?) SE memory would've been wasteful.
It raises a question if the so similar Digital Car Key dual-applet system works the same way.
Nicolaus Copernicus was a Renaissance polymath, active as a mathematician, astronomer, and Catholic canon. - Wikipedia.
Besides, Copernicus is the codename of the applet used by Apple Home Keys.
Apple OS internals contain not one, but three codenames that start with such a name:
CopernicusCar
;CopernicusHome
;CopernicusAccess
.
Taking a deeper look, we find out that all of those applets share the same primary internal AID A000000704D011500000000002000000
and container AID A000000704D011500000000001000000
, which also means that they share the same implementation.
This explains why there is so much overlap between the Car Key protocol (as described in an overview video), and a Home Key protocol. Because it's the same code base, just with some features/quirks for each subtype turned on and off for particular instances.
It also tells us that there is a third, publicly unknown "Access" implementation.
The one based not on Seos (offices) or Mifare (hotels, offices, theme parks), but on the same Copernicus standard.
This "Access" applet could be the one used in solutions provided to Hotels and managed Properties, the ones which have built-in sharing functionality. The only one real-life implementation of this protocol variation was presumably done by Salto, as they are the only ones who offer native in-wallet key sharing.
It also explains why the attestation exchange part of the Home Key protocol seemed too complex for the task it was aiming to achieve, especially the storage of validity dates, floor and room access flags, etc.
In the context of shared/managed properties all of that info could be used for "offline synchronization", as an endpoint would be able to prove access to a particular zone of the property without a need for a reader to ring up a backend and continuously synchronize a list of allowed users.
UnifiedAccess is the Passkit framework codename for Copernicus-based access passes.
Both the Home and Access Keys have system references which start with purpleTrustAir
.
Considering that Car Keys have no such references, my guess is that it could be related to networked pairing or Bluetooth subsystems (air), which are unused in the former case.
Car, Home, Access applets have references to them that start or end with pta
.
Coincidentally, Apple Cash Card is named ptc
, which could mean that pt
is a prefix for internally-developed applets, with c
standing for Cash
and a
standing for Access
.
Passkit framework defines following ISO18013 credential storage partitions:
- Identity
- UnifiedAccess
It proves that the usage of ISO18013 by UnifiedAccess was not a "one-time quick hack" but more like "temporary solutions are permament".
Considering that ISO18013 for a Home Key can be found on a file system, it raises a question if it's the same for Identity, or if the different Partition
part actually means that Identity document in stored somewhere else?
Note
SEP (Secure Enclave Processor) and SE (Secure Element) are two different things. SE is a separate certified chip, usually packaged together with an NFC controller, which runs primitive but hardened JCOP OS implementation. SEP (TrustZone) is a part of the CPU, running a separate manufacturer-provided OS. While SEP boasts greater power compared to SE, it also presents a higher vulnerability risk.
Indeed, Apple doesn't claim that ISO18013 Identity runs on the secure element. Instead, they say:
The information reflected on the user’s ID in Apple Wallet is stored in an encrypted format protected by the Secure Enclave.
By storing the private key for ID authentication in the iPhone device’s Secure Element, the ID is bound to the same device that the state-issuing authority created the ID for"
Which means that base ISO18013 identity data is not stored in the secure element, but is instead stored in the file system either in an SEP-key-backed encrypted form, or a plain form, with SE only being used for crypto proof generation.
So Apple's ISO18013 implementation runs exclusively via HCE, with SE serving only for key storage, so quite similar to newer Android devices with StrongBox? Eh :))?.
Considering that the CCC Digital Car Key implementation is based primarily on work done by Apple, it's quite probable that the upcoming Aliro standard will also borrow big chunks of current Apple Car/Home/Access key implementation.
The feature that could undego the most changes will be the "attestation exchange" part.
Aliro is planned as "multi-Architecture" and "multi-purpose", so it will contain the same features needed by shared and private properties, such as:
- Sharing and offline-enabled invitations (Attestations):
- Simplified non-ISO18013 based flow;
- Access zone masks;
- Date and validity periods;
- Limitations on buddy/multiple devices, ability to share.
- Configuration synchronization: (Mailboxes):
- Revocations;
- Setting updates.
- Multiple radio standard support:
- Bluetooth;
- UWB.
All Copernicus-based Car/Home/Access applets share the same implementation with same memory usage regardless of instance type.
According to Passkit framework (thanks to SE memory management screen), the usage is as follows (numbers in bytes):
Type | CLEAR_ON_DESELECT (cod) | CLEAR_ON_RESET (cor) | PERSISTANT_HEAP (pHeap) |
---|---|---|---|
Selectable | 124 | 19 | 7348 |
Package | 0 | 0 | 54356 |
Personalized | 124 | 0 | 5900 |
Container | 4203 | 332 | 1496 |
Copernicus executable code (Package) takes 54356 bytes (54 KB), with each instance (Personalized) taking an additional 5900 bytes each.
Modern IOS devices have about 0.7MB of memory available for users, which means that a user will be able to add about (700000 - 54356) / 5900 = 109
keys until the memory runs out.
In reality, due to nature of JCOP, GC and other things (such as additional provisioning for Selectable and Container memory, which I'm not entirely sure about, tell me if you know), the real number could differ.
Also, considering that a real user will install other applets, this amount could drop significantly, but regardless of that no normal person will ever reach the limit.
- If you find any mistakes/typos or have extra information to add, feel free to raise an issue or create a PR;
- Please be aware that the information presented here is based on personal findings, observations and assumptions, so there's no guarantee that it's correct in its entirety;
- Communication examples can be viewed in resources directory.
- Resources that helped with research:
- Parallel Home Key protocol research project:
- Original inspiration:
- General:
- TLV8 format;
- List of digital keys in mobile wallets;
- IPSW.me - used to get IOS IPSW to look for clues in a file system;
- TLV Utilities;
- ASN1 decoder;
- NDEF parser;
- CBOR playground.
- Source code:
- Apple resources:
- Device brochures:
- Other:
- Devices and software used for analysis:
- HAP-NodeJS - used to create virtual lock instances in order to look at communication and data structures;
- Proxmark3 Easy - used to sniff Home Key transactions. Proxmark3 RDV2/4 can also be used;
- Proxmark3 Iceman Fork - firmware for Proxmark3.