பெயரிங் பாய்வு

பொருளடக்கம்

• பெயரிங் ஏன் தேவை
• நம்பிக்கை மாதிரி & மறையாக்கவியல்
• கூறு வரைபடம்
• கண்டுபிடிப்பு கட்டம்
• பெயரிங் வரிசை (சிறந்த பாதை)
• விசைப் பரிமாற்ற விவரங்கள்
• பதிலளிப்பவரின் ஏற்க/நிராகரி பாய்வு
• ரத்து பாய்வு
• இரு-சேனல் வழங்கல் (LAN + BLE)
• அமர்வு & பியர் சேமிப்பு
• பாதுகாப்பு பண்புகள்
• நிலை இயந்திர சுருக்கம்

பெயரிங் ஏன் தேவை {#why-pairing-exists}

PlainApp-க்கு மையக் கணக்கு சேவையகம் இல்லை. எனவே சாதனங்கள் பேசுவதற்கு முன்பு இரண்டு கேள்விகளுக்கு பதிலளிக்க வேண்டும்:

1. "நீங்கள் யார்?" — ஒவ்வொரு சாதனமும் முதல் தொடக்கத்தில் ஒரு நிலையான clientId-ஐ உருவாக்குகிறது (அதன் Ed25519 விசைப் பொருளிலிருந்து பெறப்பட்ட 13-எழுத்து id). இது ரூட்டிங், presence, மற்றும் சேனல் உறுப்பினருக்காகப் பயன்படுத்தப்படும் ஒரே அடையாளங்காட்டி.
2. "உங்களை நம்பலாமா?" — அடையாளத்திற்கு உத்தரவாதம் அளிக்க சேவையகம் இல்லாததால், ஒரு பியர் தான் கூறும் நபரே என்பதை உறுதிப்படுத்த ஒரே வழி, ஒரு மனிதர் இரு சாதனங்களிலும் பெயரிங்கை உறுதிப்படுத்துவதும், நெறிமுறை மறைகுறியாக்க கையொப்பங்களைச் சரிபார்ப்பதும் ஆகும்.

பெயரிங் ஒரு பொருளை உருவாக்குகிறது: தரவுத்தளத்தில் ஒரு DPeer வரிசை, அதில் status="paired", ஒரு ChaCha20 key (பகிரப்பட்ட போக்குவரத்து ரகசியம்), மற்றும் பியரின் Ed25519 public_key (எதிர்கால செய்தி கையொப்பங்களைச் சரிபார்க்க). அதற்குப் பின்னர் வரும் அரட்டை துணை அமைப்பில் உள்ள ஒவ்வொரு நெறிமுறையும் இந்த இரண்டு புலங்கள் இருப்பதைக் கருதுகிறது.

நம்பிக்கை மாதிரி & மறையாக்கவியல் {#trust-model--cryptography}

பெயரிங் இரண்டு சுயாதீன மறைகுறியாக்க முதன்மைகளைப் பயன்படுத்துகிறது:

PIN இல்லை, QR குறியீடு இல்லை, out-of-band குறியீடு இல்லை. நம்பிக்கை பின்வருமாறு நிறுவப்படுகிறது:

1. ஒரு மனிதர் பதிலளிக்கும் சாதனத்தில் ஏற்க என்பதைத் தட்டுகிறார் (பயனர் "ஆம், இதுதான் நான் பெயர் செய்ய விரும்பும் சாதனம்" என உறுதிப்படுத்துகிறார்).
2. இரு தரப்பும் கோரிக்கை/பதிலில் மறுபக்கத்தின் Ed25519 கையொப்பத்தைச் சரிபார்க்கின்றன (பதிலளிப்பவர் அமர்வைத் தொடங்கிய அதே சாதனத்துடன் பேசுகிறார் என்பதையும், நேர்மாறாகவும் நிரூபிக்கிறது).
3. இரு செய்திகளிலும் ±5 நிமிட நேரமுத்திரைச் சாளரம் (பழைய பிடிக்கப்பட்ட handshake-ஐ மறுபயன்பாட்டைத் தடுக்கிறது).

சமச்சீரின்மை முக்கியம்: ஒரு மனித உறுதிப்படுத்தல் மட்டும் man-in-the-middle-க்கு பலவீனமாக இருக்கும் (தாக்குபவர் இரு தரப்புடனும் தனித்தனியாகப் பெயர் செய்யலாம்). ECDH பொது விசையில் Ed25519 கையொப்பம் இதைத் தடுக்கிறது — பதிலளிப்பவர், கோரிக்கை அமர்வைத் தொடங்கிய அதே Ed25519 விசையால் கையொப்பமிடப்பட்டது என்பதைச் சரிபார்க்கிறார், நேர்மாறாகவும், எனவே ஒரு MITM நீண்டகால கையொப்ப விசையைக் கட்டுப்படுத்தாமல் தனது சொந்த ECDH விசையை வெளிப்படையாக மாற்ற முடியாது.

கூறு வரைபடம் {#component-map}

எல்லா பெயரிங் குறியீடும் discover/ தொகுப்பில் உள்ளது (chat/peer/pair/-இல் இல்லை):

கோப்பு இடங்கள்

கண்டுபிடிப்பு கட்டம் {#discovery-phase}

பெயரிங் நிகழ்வதற்கு முன்பு, சாதனங்கள் ஒன்றையொன்று கண்டுபிடிக்க வேண்டும். செயலி தொடங்கியவுடன் LANDiscoverManager தொடர்ச்சியாக இயங்குகிறது:

இயக்கப்பட்ட கண்டுபிடிப்பு ஏன் மறைகுறியாக்கப்பட்டுள்ளது

ஒளிபரப்பு DISCOVER எதையும் உணர்வுபூர்வமாக வெளிப்படுத்துவதில்லை (வெறும் fromId=clientId), எனவே LAN-ல் உள்ள எந்தச் சாதனமும் அதைப் பார்ப்பது பிரச்சனையில்லை. இருப்பினும், இயக்கப்பட்ட மாறுபாடு, ஒரு சாதனம் ஏற்கனவே மற்றொரு சாதனத்தின் clientId-ஐ அறியும்போது (உ.ம். பெயர் செய்யப்பட்டது ஆனால் பியரின் IP மாறிவிட்டது) அதை எழுப்ப விரும்பும்போது பயன்படுத்தப்படுகிறது. இலக்கு clientId-ஐ பியரின் பகிரப்பட்ட விசையுடன் மறைகுறியாக்குவது பொருள்:

• சரியான பியர் toId-ஐ மறைநீக்கம் செய்து, தன்னை அடையாளம் காட்டி, பதிலளிக்க முடியும்.
• LAN-ல் உள்ள மற்ற எல்லா சாதனங்களும் வெறும் ciphertext-ஐ மட்டுமே பார்க்கின்றன — அவை அனுப்புநர் எந்தெந்த clientId-களை அடைய முயல்கிறார் என்பதைப் பட்டியலிட முடியாது.

இது சிறிய ஆனால் உண்மையான தனியுரிமைப் பண்பு: செயலற்ற LAN பார்வையாளர்கள் யார் யாருடன் பெயர் செய்துள்ளார்கள் என்ற வரைபடத்தை உருவாக்க முடியாது.

பதிலில் உள்ள Aware கொடிகள்

DISCOVER_REPLY awareSupported மற்றும் awareRunning-ஐக் கொண்டு செல்கிறது. இவை தரவுத்தளத்தில் நிலைத்திருக்காது — அவை PeerCacher-இல் நினைவகத்தில் சேமிக்கப்பட்டு ஒவ்வொரு பதிலிலும் (மேலும் BLE scan-response serviceData-இலிருந்தும்) புதுப்பிக்கப்படுகின்றன. போக்குவரத்து அடுக்கு அவற்றை ஆலோசித்து, Wi-Fi Aware இணைப்பை முயற்சிக்கலாமா அல்லது நேரடியாக BLE-க்குச் செல்லலாமா என்பதைத் தீர்மானிக்கிறது.

பெயரிங் வரிசை (சிறந்த பாதை) {#pairing-sequence-happy-path}

இரு சாதனங்களும் ஒரே LAN-ல் இருக்கும்போதும் பயனர் பெயரிங்கை ஏற்கும்போதுமான முழுமையான பாய்வு:

இரு தரப்பும் பியரை ஏன் தனித்தனியாகச் சேமிக்கின்றன

தொடக்கியவரும் (படி 9) பதிலளிப்பவரும் (படி 7) மறு சாதனத்திற்காக PairingPeerStore.save(...)-ஐ அழைப்பதைக் கவனியுங்கள். இது வேண்டுமென்றே செய்யப்பட்டது: ஒவ்வொரு சாதனமும் மறுபக்கத்தின் clientId-ஆல் திறமுடைய ஒரு DPeer வரிசையுடன் முடிகிறது, அதில் தனது சொந்த பகிரப்பட்ட ChaCha20 விசை மற்றும் மறுபக்கத்தின் Ed25519 பொது விசை இரண்டும் இருக்கும். மையப் பதிவேடு இல்லை — பெயரிங் சமச்சீர் மற்றும் சுயமாகவே நிறைந்தது.

பதிலளிப்பவர் விசையை முதலில் ஏன் கணக்கிடுகிறார்

பதிலளிப்பவரின் acceptPairingRequest ஏற்பதற்கு உடனடியாகப் பகிரப்பட்ட விசையைக் கணக்கிட்டு நிலைத்திருக்கச் செய்கிறது. இதன் பொருள் பதிலளிப்பவர் மறைகுறியாக்கப்பட்ட போக்குவரத்தை பதில் தொடக்கியவரிடம் திரும்பி வருவதற்கு முன்பே பெறத் தொடங்கலாம். பதில் பரிமாற்றத்தில் தொலைந்துபோனால், பதிலளிப்பவர் இன்னும் பெயர் செய்யப்பட்டவராகவே இருக்கிறார் — தொடக்கியவருக்கு மட்டுமே மறுமுயற்சி தேவை.

விசைப் பரிமாற்ற விவரங்கள் {#key-exchange-details}

பெயரிங்கின் மறைகுறியாக்க மையம் ஒரு தரநிலை X25519-பாணி ECDH விசை ஒப்பந்தம், ஆனால் அதை அங்கீகரிக்க அதன் மேல் Ed25519 கையொப்பம் அடுக்கப்பட்டுள்ளது.

கையொப்பம் உண்மையில் எதைப் பாதுகாக்கிறது

கையொப்பமிடப்பட்ட சுமை (toSignatureData()) நிலையான கோரிக்கை புலங்களின் நியமக் கோர்ப்பு: fromId, fromName, port, deviceType, ecdhPublicKey, signaturePublicKey, timestamp, மற்றும் ips. ecdhPublicKey-ஐ நீண்டகால signaturePublicKey-உடன் சேர்த்து கையொப்பமிடுவதன் மூலம், நெறிமுறை தற்காலிக விசையை சாதனத்தின் அடையாளத்துடன் பிணைக்கிறது. ஒரு தாக்குபவர் கையொப்பத்தை செல்லுபடியற்றதாக்காமல் பரிமாற்றத்தில் தங்களது சொந்த ECDH பொது விசையை மாற்ற முடியாது — மேலும் அவர்கள் நீண்டகால Ed25519 விசையைக் கட்டுப்படுத்தாமல் கையொப்பத்தைப் போலி செய்ய முடியாது.

இதுதான் man-in-the-middle-ஐ தோற்கடிக்கிறது: தாக்குபவர் இரு சாதனங்களுக்கிடையே ஒவ்வொரு பாக்கெட்டையும் ரிலே செய்தாலும், அவர்களால் மறைகுறியாக்கப்பட்ட போக்குவரத்தைப் படிக்க முடியாது (ஏனெனில் இரு பக்கத்தின் ECDH தனிப்பட்ட விசையும் அவர்களிடம் இல்லை) மற்றும் தங்கள் சொந்த ECDH விசைகளை மாற்ற முடியாது (ஏனெனில் கையொப்பங்கள் உடைந்துவிடும்).

பதிலளிப்பவரின் ஏற்க/நிராகரி பாய்வு {#responder-acceptdecline-flow}

PAIR_REQUEST வரும்போது பதிலளிப்பவர் பக்கம் ஒரு UI உரையாடலைக் காட்டுகிறது. பயனர் ஏற்கவோ அல்லது நிராகரிக்கவோ செய்யலாம்.

பதிலளிப்பவர் ஏற்பதற்கு உடனடியாக PairingSuccessEvent-ஐ ஏன் இயக்குகிறார்

பதிலளிப்பவரின் acceptPairingRequest PairingPeerStore.save(...)-ஐ அழைத்து பதில் அனுப்புவதற்கு முன்பே PairingSuccessEvent-ஐ இயக்குகிறது. இது வேண்டுமென்றே செய்யப்பட்டது: பதில் தொடக்கியவரை வந்தடையவில்லை என்றால் (நெட்வொர்க் கோளாறு), பதிலளிப்பவர் இன்னும் பெயர் செய்யப்பட்டவராகவே இருக்கிறார் — அடுத்த முறை தொடக்கியவர் பெயர் செய்ய முயற்சிக்கும்போது, பதிலளிப்பவரின் ஏற்கனவே-இருக்கும் DPeer வரிசை presence அமைப்பால் எடுத்துக்கொள்ளப்படும். தொடக்கியவர் வெறுமனே மறுமுயற்சி செய்கிறார்; பதிலளிப்பவர் மீண்டும் உறுதிப்படுத்த வேண்டியதில்லை.

ரத்து பாய்வு {#cancel-flow}

நிகழ்ந்துகொண்டிருக்கும் பெயரிங்கை இரு தரப்பும் ரத்து செய்யலாம்.

DPairingCancel LAN unicast-இல் மட்டுமே அனுப்பப்படுகிறது (தொடக்கியவருக்கு கண்டுபிடிப்பு கட்டத்திலிருந்தே பதிலளிப்பவரின் IP உள்ளது), அதேசமயம் நிராகரிப்பு பதில் LAN மற்றும் BLE இரண்டிலும் அனுப்பப்படுகிறது, ஏனெனில் பதிலளிப்பவரால் தொடக்கியவர் எந்தப் போக்குவரத்தில் அடையக்கூடியவர் என்பதை உறுதியாகத் தெரியவில்லை.

இரு-சேனல் வழங்கல் (LAN + BLE) {#dual-channel-delivery-lan--ble}

பதிலளிப்பவர் DPairingResponse-ஐ அனுப்பும்போது, LAN மற்றும் BLE இரண்டிலும் ஒரே நேரத்தில் அனுப்புகிறார். தொடக்கியவர் முதல் நகலை ஏற்றுக்கொண்டு, நகலை அமைதியாகக் கைவிடுகிறார்.

BlePairingSessionStore ஏன் இருக்கிறது

PAIR_REQUEST BLE வழியாக வரும்போது, பதிலளிப்பவரிடம் தொடக்கியவருக்கான LAN IP இருக்காது — வெறும் அவரது BLE MAC முகவரி மட்டுமே. BlePairingSessionStorepeerId → MAC வரைபடத்தை உருவாக்குகிறது, இதனால் தேவைப்பட்டால் பதில் BLE வழியாகத் திருப்பி அனுப்பப்படலாம். இது ஒரு சிறிய, நினைவகத்தில் இருக்கும், தற்காலிக வரைபடம், BLE-வழி கோரிக்கைகளுக்கு மட்டுமே நிரப்பப்பட்டு, பதில் அனுப்பப்பட்டவுடன் அழிக்கப்படுகிறது.

அமர்வு & பியர் சேமிப்பு {#session--peer-storage}

இரு சேமிப்புகள் பெயரிங்கில் பங்கேற்கின்றன, மிகவும் வேறுபட்ட வாழ்க்கைச்சுழற்சியுடன்:

clientId மட்டுமே நிலைத்த அடையாளங்காட்டியாக ஏன் இருக்கிறது

Android ஒவ்வொரு இணைப்பிலும் BLE MAC முகவரியை சீரற்றதாக்குகிறது, எனவே அதைச் சேமிப்பது பயனற்றது. clientId சாதனத்தின் நீண்டகால Ed25519 விசைப் பொருளிலிருந்து பெறப்படுகிறது, எனவே அது:

• செயலி மறுநிறுவல்களில் நிலையானது (விசை தளத் கீஸ்டோரில் உள்ளது).
• சுய-அங்கீகரிப்பது — ஒரு clientId-ஐ உரிமை கோருபவர் தாங்கள் தொடர்புடைய Ed25519 தனிப்பட்ட விசையை வைத்திருப்பதை நிரூபிக்க வேண்டும் (ஒவ்வொரு கையொப்ப செய்தியிலும் சரிபார்க்கப்படுகிறது).
• தனியுரிமையைப் பாதுகாப்பது — 8-பைட் SHA-256 முன்னொட்டம் (shortId) மட்டுமே கண்டுபிடிப்புக்காக BLE வழியாக ஒளிபரப்பப்படுகிறது; முழு clientId நீங்கள் உண்மையில் பெயர் செய்யும் சாதனங்களுக்கு மட்டுமே வெளிப்படுத்தப்படுகிறது.

பாதுகாப்பு பண்புகள் {#security-properties}

பெயரிங் எதற்கு எதிராகப் பாதுகாக்கவில்லை

• பௌதீக சாதன இடைமறிப்பு. ஒரு தாக்குபவர் பெயர் செய்த சாதனத்தில் root பெற்றால், அவர்களால் தரவுத்தளத்திலிருந்து பகிரப்பட்ட விசையைப் படித்து அந்தப் பியராக நடிக்க முடியும். பகிரப்பட்ட போக்குவரத்து விசைக்கு வன்பொருள்-ஆதரவு கீஸ்டோர் செயல்படுத்தல் இல்லை (Ed25519 கையொப்ப விசைக்கு மட்டுமே, SignatureHelper வழியாக).
• செயலில் ரிலே தாக்குதல்கள். ஒரு தாக்குபவரால் ஒரே நேரத்தில் இரு சாதனங்களுக்கிடையே BLE மற்றும் LAN போக்குவரத்தை ரிலே செய்து, அவை ஒன்றையொன்று பெயர் செய்வதாக நினைப்பதை நடுவில் நிறுத்த முடியும் — ஆனால் ECDH பொது விசையில் Ed25519 கையொப்பம் என்பது அவர்களால் போக்குவரத்தைப் படிக்க முடியாது, வெறுமனே ரிலே செய்ய மட்டுமே முடியும் என்பதாகும். இது எண் ஒப்பீடு இல்லாத Bluetooth பெயரிங் போன்றே அதே பரிமாற்றம்.
• நெட்வொர்க்-நிலை தடுப்பு. ஒரு ஃபயர்வால் UDP மல்டிகாஸ்ட்டைத் தடுக்கலாம், BLE ஜாம் செய்யப்படலாம், Wi-Fi Aware கிடைக்காமல் போகலாம். அமைப்பு அருகாமையாகச் செயலிழக்கிறது (BLE பெயர் செய்த பியர்களுக்கு உத்தரவாதமான fallback) ஆனால் செயலில் விரோதமான நெட்வொர்க்கைத் தவிர்க்க முடியாது.

நிலை இயந்திர சுருக்கம் {#state-machine-recap}

மேலும் படிப்பதற்கு

• அரட்டைக் கட்டமைப்பு — பகிரப்பட்ட விசை எதற்குப் பயன்படுத்தப்படுகிறது: பியர் அரட்டை அனுப்பு/பெறு, சேனல் fan-out, presence, கோப்பு பதிவிறக்கங்கள்.
• apitest/groups/discovery.sh — கண்டுபிடிப்பு மற்றும் பெயரிங் API மேற்பரப்பை முழுமையாகச் சோதிக்கும் இயங்கக்கூடிய சோதனைத் திட்டம்.