Meari ಬೇಬಿ ಕ್ಯಾಮೆರಾದ ಭದ್ರತಾ ದುರ್ಬಲತೆ: Timmy ವಿಭಿನ್ನವಾಗಿ ಮಾಡುವುದೇನು

Galaxus ಮುಕ್ತವಾಗಿ ಪ್ರವೇಶಿಸಬಹುದಾಗಿದ್ದ ಬೇಬಿ ಕ್ಯಾಮೆರಾ ರೆಕಾರ್ಡಿಂಗ್‌ಗಳ ಬಗ್ಗೆ ವರದಿ ಮಾಡಿತು; The Verge ಸುಮಾರು 1.1 ಮಿಲಿಯನ್ Meari ಸಾಧನಗಳು ಪರಿಣಾಮಕ್ಕೊಳಗಾಗಿವೆ ಎಂದು ವರದಿ ಮಾಡಿತು. ನನಗೆ ಇದರಿಂದ ಸಿಗುವ ಪಾಠ ಸರಳವಾಗಿದೆ: ಹಿಂದೆ ಇರುವ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಪ್ರತಿ ಸಾಧನದ ಮಟ್ಟದಲ್ಲಿ ಸಂದೇಶಗಳು, ಚಿತ್ರಗಳು ಅಥವಾ ಕೀಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಪ್ರತ್ಯೇಕಿಸದಿದ್ದರೆ, ಲಾಗಿನ್ ಮಗುವಿನ ಕೋಣೆಯನ್ನು ರಕ್ಷಿಸುವುದಿಲ್ಲ. Timmy ಜಗತ್ತಿನ ಎಲ್ಲ ಭದ್ರತಾ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುವುದಿಲ್ಲ. ಆದರೆ Timmyಯ ಪ್ರಮುಖ ಮೀಡಿಯಾ ಮತ್ತು ಪೇರಿಂಗ್ ರಹಸ್ಯಗಳು ಕ್ಲೌಡ್-ಕ್ಯಾಮೆರಾ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ಇರುವುದಿಲ್ಲ.

ಹಾರ್ಡ್‌ವೇರ್ ಅಥವಾ ಆ್ಯಪ್ ನಿಜವಾದ ಭೇದವಲ್ಲ

ಭೌತಿಕ ಬೇಬಿ ಕ್ಯಾಮೆರಾ ಮತ್ತು ಫೋನ್ ಆಧಾರಿತ ಬೇಬಿ ಮಾನಿಟರ್ ಆ್ಯಪ್ ಎರಡೂ ಒಂದೇ ಮೂಲ ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸುತ್ತವೆ: ಖಾಸಗಿ ಕುಟುಂಬದ ಕೋಣೆಯಲ್ಲಿ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಸಂಪರ್ಕಿತ ಮೈಕ್ರೋಫೋನ್ ಮತ್ತು ಕ್ಯಾಮೆರಾವನ್ನು ಇರಿಸಲಾಗುತ್ತದೆ. ಉತ್ಪನ್ನವು ಹಾರ್ಡ್‌ವೇರ್ ಅಥವಾ ಸಾಫ್ಟ್‌ವೇರ್ ಎಂಬುದು ಮುಖ್ಯವಲ್ಲ; ಬೇರೆ ಖಾತೆಯೊಂದು ಬೇರೊಬ್ಬರ ಸೆಷನ್‌ಗೆ ಗುಪ್ತವಾಗಿ ಪ್ರವೇಶ ಪಡೆಯದಂತೆ ಖಾತೆಗಳು, ಸಾಧನಗಳು, ಬ್ರೋಕರ್‌ಗಳು, ಸಂಗ್ರಹಣೆ, ರಿಲೇಗಳು ಮತ್ತು ಕೀಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆಯೇ ಎಂಬುದೇ ಮುಖ್ಯ.

Meari ಘಟನೆಯಲ್ಲಿ ಏನು ವಿಫಲವಾಗಿರಬಹುದು

ಸಾರ್ವಜನಿಕ ವರದಿಗಳು ವೈಟ್-ಲೇಬಲ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ವೊಂದನ್ನು ವಿವರಿಸುತ್ತವೆ. ಗ್ರಾಹಕರಿಗೆ ಬೇರೆ ಬೇರೆ ಹೆಸರಿನಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡ ಹಲವು ಬ್ರ್ಯಾಂಡ್‌ಗಳು ಅದೇ Meari/CloudEdge ಮೂಲಸೌಕರ್ಯವನ್ನು ಅವಲಂಬಿಸಿದ್ದ ಕ್ಯಾಮೆರಾಗಳನ್ನು ಮಾರಿದ್ದವು. ಅದಕ್ಕಾಗಿಯೇ ಈ ಘಟನೆ ಮುಖ್ಯ: ಹಂಚಿಕೆಯ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನುಮತಿಯ ಗಡಿಯನ್ನು ತಪ್ಪಾಗಿ ನಿಗದಿಪಡಿಸಿದರೆ, ಪರಿಣಾಮವು ಒಂದೇ ದುರ್ಬಲ ಕ್ಯಾಮೆರಾಗೆ ಸೀಮಿತವಾಗದೆ ಇಡೀ ಸಾಧನ ಸಮೂಹದ ಮಾಹಿತಿ ಬಹಿರಂಗವಾಗುವಿಕೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ.

ವರದಿಯಾದ ಮಾದರಿಯು ದುರ್ಬಲ ಡೀಫಾಲ್ಟ್ ಪಾಸ್‌ವರ್ಡ್‌ಗಳ ಸಮಸ್ಯೆಗಿಂತಲೂ ಗಂಭೀರವಾಗಿದೆ. ಪ್ರತಿ ಸಾಧನಕ್ಕೂ ಸಾಕಷ್ಟು ಪ್ರತ್ಯೇಕ ಚಂದಾದಾರಿಕೆ ನಿಯಂತ್ರಣಗಳಿಲ್ಲದ MQTT ಸಂದೇಶಗಳು, ಸಾರ್ವಜನಿಕವಾಗಿ ತಲುಪಬಹುದಾದ ಚಿತ್ರ URL‌ಗಳು, ದುರ್ಬಲ ಚಿತ್ರ ಮರೆಮಾಚುವಿಕೆ ಮತ್ತು ಸ್ಥಿರವಾಗಿರುವ ಅಥವಾ ಆ್ಯಪ್‌ನಿಂದ ಹೊರತೆಗೆಯಬಹುದಾದ ಕೀಗಳ ಕುರಿತು ಮೂಲಗಳು ವಿವರಿಸುತ್ತವೆ. ಇದು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ವೈಫಲ್ಯ: ಬೇರೆ ಖಾತೆಗೆ ಎಂದಿಗೂ ಲಭ್ಯವಾಗಬಾರದ ಡೇಟಾವನ್ನು ಮೂಲಸೌಕರ್ಯವೇ ಬಹಿರಂಗಪಡಿಸಬಹುದಾಗಿತ್ತು.

ಕ್ಲೌಡ್-ಕ್ಯಾಮೆರಾದ ಅಪಾಯ	Timmyಯ ಪರ್ಯಾಯ ವಿನ್ಯಾಸ
ಬ್ಯಾಕ್‌ಎಂಡ್ ಚಿತ್ರಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಈವೆಂಟ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ ಅಥವಾ ವಿತರಿಸುತ್ತದೆ.	Timmyಯಲ್ಲಿ ಮಗುವಿನ ಕೋಣೆಯ ಚಿತ್ರಗಳಿಗೆ ಕ್ಲೌಡ್ ಆರ್ಕೈವ್ ಇಲ್ಲ; ಮೀಡಿಯಾ ಲೈವ್ WebRTC ಆಗಿದೆ.
ಬ್ರೋಕರ್ ಅಥವಾ ಬಕೆಟ್ ಪ್ರತಿಯೊಂದು ಸಾಧನಕ್ಕೂ ನಿಖರವಾಗಿ ಅನುಮತಿ ನೀಡಲೇಬೇಕು.	Firestore ಕೇವಲ ಪೇರಿಂಗ್ ಮತ್ತು ಸಿಗ್ನಲಿಂಗ್ ಡೇಟಾವನ್ನು ಸಾಗಿಸುತ್ತದೆ; SDP/ICE ಬರೆಯುವ ಮುನ್ನವೇ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಆಗಿರುತ್ತದೆ.
ಸ್ಥಿರ ಕೀಗಳು ಇಡೀ ಸಾಧನ ಸಮೂಹದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವ ಸಾಧ್ಯತೆ ಇದೆ.	ಪ್ರತಿ ಪೇರಿಂಗ್‌ನಲ್ಲೂ ಸಾಧನಗಳಲ್ಲಿಯೇ ಪ್ರತ್ಯೇಕವಾದ P-256 ECDH ಆಧಾರಿತ ಕೀ ವ್ಯುತ್ಪನ್ನಗೊಳ್ಳುತ್ತದೆ.
ರಿಲೇ ಮಾರ್ಗವನ್ನು ಮೀಡಿಯಾ ಪ್ರವೇಶವೆಂದು ತಪ್ಪಾಗಿ ಭಾವಿಸಬಹುದು.	TURN ಎನ್‌ಕ್ರಿಪ್ಟ್ ಆದ SRTP ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತದೆ, ಆದರೆ ಮೀಡಿಯಾ ಕೀಗಳನ್ನು ಪಡೆಯುವುದಿಲ್ಲ.

Timmy ರಹಸ್ಯವನ್ನು ಹೇಗೆ ರಚಿಸುತ್ತದೆ

ನಾಲ್ಕು ಚಿಹ್ನೆಗಳ Timmy ಕೋಡ್ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ರಹಸ್ಯವಾಗಿಲ್ಲ. ತಾಂತ್ರಿಕವಾಗಿ ಅದು ಕೇವಲ ಸಂಪರ್ಕ ಕಲ್ಪಿಸುವ ಬಿಂದುವಷ್ಟೇ: ಆ್ಯಪ್ ಅದರಿಂದ ಒಂದು ಮೀಟಿಂಗ್ ಕೀಲಿಯನ್ನು ವ್ಯುತ್ಪನ್ನಗೊಳಿಸುತ್ತದೆ, meetingKey ಇದರಿಂದ ಎರಡೂ ಸಾಧನಗಳು ಒಂದೇ Firestore ಸಾರ್ವಜನಿಕ-ಕೀ ವಿನಿಮಯವನ್ನು ಕಂಡುಕೊಳ್ಳಬಹುದು. ಖಾಸಗಿ ECDH ಕೀಗಳು ಎಂದಿಗೂ ಸಾಧನಗಳಿಂದ ಹೊರಗೆ ಹೋಗುವುದಿಲ್ಲ.

ನಂತರ ಎರಡೂ ಸಾಧನಗಳು ಒಂದೇ P-256 ECDH ಹಂಚಿಕೆಯ ರಹಸ್ಯವನ್ನು ಲೆಕ್ಕಹಾಕುತ್ತವೆ. ಪೇರಿಂಗ್ ಕೀ ಸ್ಥಳೀಯವಾಗಿಯೇ ವ್ಯುತ್ಪನ್ನಗೊಳ್ಳುತ್ತದೆ. ಎರಡು ಅಂಕಿಯ SAS ಅನ್ನು ಹಂಚಿಕೆಯ ರಹಸ್ಯ ಮತ್ತು ಕ್ರಮಬದ್ಧವಾಗಿ ಜೋಡಿಸಿದ ಎರಡೂ ಸಾರ್ವಜನಿಕ ಕೀಗಳಿಂದ ವ್ಯುತ್ಪನ್ನಗೊಳಿಸಲಾಗುತ್ತದೆ. ಆ ಕೀ ವಿನಿಮಯದಲ್ಲಿ ಯಾರಾದರೂ ಹಸ್ತಕ್ಷೇಪ ಮಾಡಿದರೆ, ಸಾಧನಗಳು ಬೇರೆ ಬೇರೆ ಸಂಖ್ಯೆಗಳನ್ನು ತೋರಿಸುತ್ತವೆ; ಇದರಿಂದ ಬಳಕೆದಾರರು ಪೇರಿಂಗ್ ಅನ್ನು ದೃಢೀಕರಿಸಬಾರದು ಎಂಬುದು ತಿಳಿಯುತ್ತದೆ.

sequenceDiagram
    participant Baby as Baby device
    participant Firestore as Firestore meeting point
    participant Parent as Parent device
    participant Turn as TURN relay

    Baby->>Baby: Generate P-256 ECDH keypair
    Parent->>Parent: Generate P-256 ECDH keypair
    Baby->>Firestore: Write public key only under meetingKey
    Parent->>Firestore: Write public key only under meetingKey
    Firestore-->>Baby: Parent public key
    Firestore-->>Parent: Baby public key
    Baby->>Baby: Compute sharedSecret + SAS
    Parent->>Parent: Compute sharedSecret + SAS
    Baby-->>Parent: Humans compare SAS on both screens
    Baby->>Firestore: Write SDP/ICE encrypted with AES-256-GCM
    Parent->>Firestore: Write SDP/ICE encrypted with AES-256-GCM
    Baby-)Turn: WebRTC media as DTLS/SRTP packets
    Turn-)Parent: Relay forwards encrypted packets
    Note over Turn: TURN sees network metadata, not media keys

ಸರಳೀಕೃತ Timmy ಭದ್ರತಾ ಸರಪಳಿ: Firestore ಭೇಟಿಯ ಮತ್ತು ಸಿಗ್ನಲಿಂಗ್ ಸಾಗಣೆಗಾಗಿ; TURN ಕೇವಲ ರಿಲೇ; ಮೀಡಿಯಾ WebRTC ಎನ್‌ಕ್ರಿಪ್ಷನ್‌ನಲ್ಲೇ ಉಳಿಯುತ್ತದೆ.

WebRTC ಮೀಡಿಯಾವನ್ನು ಗುಪ್ತವಾಗಿ ಏಕೆ ವೀಕ್ಷಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ

WebRTC ಎಂದರೆ ಕೇವಲ “ವೀಡಿಯೊ ಕಳುಹಿಸಿ” ಎಂದಲ್ಲ. ಮೀಡಿಯಾ ಹರಿಯುವ ಮೊದಲು ಸಾಧನಗಳು DTLS ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಮಾಡುತ್ತವೆ. ಆಡಿಯೊ ಮತ್ತು ವೀಡಿಯೊಗೆ ಬೇಕಾದ SRTP ಕೀಗಳು ಈ ಸುರಕ್ಷಿತ ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್‌ನಿಂದ ಉತ್ಪನ್ನಗೊಳ್ಳುತ್ತವೆ. ನಂತರ ಮೀಡಿಯಾ ಪ್ಯಾಕೆಟ್‌ಗಳು SRTP ರೂಪದಲ್ಲಿ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಆಗುತ್ತವೆ. TURN ಸರ್ವರ್ ಆ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡಬಹುದು, ಆದರೆ ಆಡಿಯೊ ಅಥವಾ ವೀಡಿಯೊ ತೆರೆಯಲು ಬೇಕಾದ ಕೀಗಳನ್ನು ಅದು ಪಡೆಯುವುದಿಲ್ಲ.

Timmy ಇದಕ್ಕೂ ಮೊದಲು ಇನ್ನೊಂದು ಪದರವನ್ನು ಸೇರಿಸುತ್ತದೆ: SDP ಆಫರ್‌ಗಳು, SDP ಉತ್ತರಗಳು ಮತ್ತು ICE ಅಭ್ಯರ್ಥಿಗಳಂತಹ ಸಿಗ್ನಲಿಂಗ್ ಡೇಟಾವನ್ನು Firestore ತಲುಪುವ ಮುನ್ನ AES-256-GCM ಬಳಸಿ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಲಾಗುತ್ತದೆ. Firestore ಸಾಧನಗಳು ಪರಸ್ಪರ ಸಂಪರ್ಕ ಹೊಂದಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ; ಅಲ್ಲಿ ಸರಳ ಪಠ್ಯದ ವೀಡಿಯೊ, ಆಡಿಯೊ ಅಥವಾ ಸಿಗ್ನಲಿಂಗ್ ಇರಬೇಕೆಂದಿಲ್ಲ.

Timmy ಇನ್ನೂ ಏನು ಹೇಳಿಕೊಳ್ಳುವುದಿಲ್ಲ

ಯಾವುದೇ ವಿಶ್ವಾಸಾರ್ಹ ಬೇಬಿ ಮಾನಿಟರ್ ತನ್ನನ್ನು ಹ್ಯಾಕ್ ಮಾಡಲು ಅಸಾಧ್ಯ ಎಂದು ಹೇಳಿಕೊಳ್ಳಬಾರದು. ಫೋನ್‌ನ ಭದ್ರತೆ ಭಂಗವಾದರೆ, ಅದರಲ್ಲಿರುವ ಯಾವುದೇ ಆ್ಯಪ್ ಮೇಲೆ ದಾಳಿ ನಡೆಸಬಹುದು. ದುರುದ್ದೇಶಪೂರಿತ ಆ್ಯಪ್ ಬಿಲ್ಡ್ ಅಪಾಯದ ಮಾದರಿಯನ್ನೇ ಬದಲಿಸುತ್ತದೆ. ಸರ್ವರ್ ಕಾನ್ಫಿಗರೇಶನ್ ಸದಾ ಸರಿಯಾಗಿರಬೇಕು. Timmyಯ ಸೀಮಿತ ಹೇಳಿಕೆ ಅದರ ವಿನ್ಯಾಸಕ್ಕೆ ಸಂಬಂಧಿಸಿದೆ: ಮಗುವಿನ ಕೋಣೆಯ ಮೀಡಿಯಾವನ್ನು ಬ್ಯಾಕ್‌ಎಂಡ್ ಓದಬಲ್ಲ ರೂಪದಲ್ಲಿ ಉಳಿಸುವುದನ್ನು ಅದು ತಪ್ಪಿಸುತ್ತದೆ ಮತ್ತು ಭದ್ರತೆಗೆ ನಿರ್ಣಾಯಕವಾದ ಪೇರಿಂಗ್ ಲಾಜಿಕ್ ಅನ್ನು ಸಾರ್ವಜನಿಕ ಕೋರ್ ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿ ಪರಿಶೀಲಿಸಲು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ.

ಯಾವುದೇ ಬೇಬಿ ಕ್ಯಾಮೆರಾ ಕುರಿತು ಕೇಳಬೇಕಾದ ಪ್ರಶ್ನೆಗಳು

ಪೂರೈಕೆದಾರರು ಚಿತ್ರಗಳು ಅಥವಾ ಕ್ಲಿಪ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತಾರೆಯೇ?
ಮೀಡಿಯಾ URL‌ಗಳು ಖಾಸಗಿ, ಅಲ್ಪಾವಧಿಯ ಮತ್ತು ಪ್ರತಿ ಸಾಧನಕ್ಕೂ ಪ್ರತ್ಯೇಕವಾಗಿ ಅನುಮತಿಸಲ್ಪಟ್ಟಿವೆಯೇ?
ಕೀಗಳನ್ನು ಆ್ಯಪ್‌ನೊಳಗೆ ಸ್ಥಿರವಾಗಿ ಇರಿಸುವ ಬದಲು ಪ್ರತಿ ಸಾಧನ ಅಥವಾ ಪೇರಿಂಗ್‌ಗೆ ರಚಿಸಲಾಗುತ್ತದೆಯೇ?
ನೀವು ನಿಜವಾಗಿಯೂ ಹೊಂದಿರುವ ಸಾಧನಕ್ಕಷ್ಟೇ ಬ್ರೋಕರ್ ಸಂದೇಶಗಳನ್ನು ತಲುಪಿಸಬಹುದೇ?
ಮಧ್ಯವರ್ತಿ ದಾಳಿಯ ಪ್ರಯತ್ನವನ್ನು ಪೇರಿಂಗ್ ವೇಳೆ ವ್ಯಕ್ತಿಯೊಬ್ಬರು ಗಮನಿಸಬಹುದೇ?

ಕೋಡ್ ಓದಿ

ಮೂಲಗಳು

← ಬ್ಲಾಗ್‌ಗೆ ಹಿಂತಿರುಗಿ