convenient features without compromising security - We are often at a crossroads between user experience and security - We always endeavor to find a solution to achieve both for our users
password, PIN, device ownership, … - Some are not good as a means of identification - Phone number ownership is mutable - And not good as a means of authentication - Knowledge factors(password, PIN, …) are too easy to forget & be leaked - We cannot expect users to use highly secure password
account takeover attacks - Our familiar weapon: Multi-factor authentication - Ex) Device ownership verification - Transfer sequence becomes longer and longer.. - Longer the transfer sequence is, harder for users to complete the transfer - More than 30% of incoming CS inquiries are about Account Transfer
damages to users - Data leakage, financial losses, … - Phishing page dupes user to provide ID, password, PIN code, … - Not easy to detect and find from service side - Our countermeasures: History of LINE's Phishing Fraud Countermeasures LINE Official Webpage: Real Examples of Phishing Scams
see all of previous chats on the new device - Not only chat history but Letter Sealing key should also be transferred - Limitation of the current cloud-based backup feature - It depends on external services like iCloud or Google Drive - Currently it cannot be restored across different device platforms
- More secure auth factor than password - Enabling better identification via device ownership - Easier transfer feature utilizes biometric authentication for user before accessing device’s key store - Note: LINE also supports biometric auth via FIDO2 - Applied to account login on LINE desktop clients
and show QR code Scan QR code Receive current device’s data (encrypted) Notify to send current device’s data Wait for current device’s data Decrypt and save data Server New Device Current Device Ask user to confirm the transfer & proceed biometric auth to unlock client’s key store Send current device’s data (encrypted)
and show QR code Scan QR code Receive current device’s data (encrypted) Notify to send current device’s data Wait for current device’s data Decrypt and save data Server New Device Current Device Send current device’s data (encrypted) Ask user to confirm the transfer & proceed biometric auth to unlock client’s key store
and show QR code Scan QR code Receive current device’s data (encrypted) Notify to send current device’s data Send current device’s data (encrypted) Wait for current device’s data Decrypt and save data Server New Device Current Device Ask user to confirm the transfer & proceed biometric auth to unlock client’s key store
and show QR code Scan QR code Receive current device’s data (encrypted) Notify to send current device’s data Wait for current device’s data Decrypt and save data Server New Device Current Device Send current device’s data (encrypted) Ask user to confirm the transfer & proceed biometric auth to unlock client’s key store
Device Notify to send current device’s data Send current device’s encrypted data Encrypted data Data C-PUB Nonce Shared Secret to encrypt data N-PUB Nonce
Device Notify to send current device’s data Send current device’s encrypted data Receive current device’s data Encrypted data Data C-PUB Nonce Shared Secret to encrypt data Encrypted data N-PUB Nonce N-PUB Nonce Shared Secret to decrypt data
Device Notify to send current device’s data Data C-PUB Nonce Shared Secret to encrypt data N-PUB Nonce Shared Secret to decrypt data Data Receive current device’s data Encrypted data N-PUB Nonce Send current device’s encrypted data
loses or breaks their current device - No way to transfer current device’s Letter Sealing key without a backup - Challenge: How can we backup & restore Letter Sealing key securely? - Server must not know the raw key value under any circumstances
Encrypt / Decrypt Backup User Input (PIN) Remaining attempt? Correct PIN? Backup / Restore Chat History Permanently Locked No remaining attempt Attempt counts LINE Dev Day 2019: Seamless device migration using LINE secure backups
restoration in Trusted Execution Environment(TEE) - Based on Intel’s Software Guard Extensions(SGX) - For more details, check our twin session in Tech-Verse Day1: - High Assurance Secure Software Development on the Server Side 2. Enforcing limits in key restoration attempts to prevent brute-force attacks - Must be resistant to internal threats from company network as well - Versioning the backup state and storing the restoration attempt count
& Restoration Process Extended storage (Persistent) Attempt counts Encrypted Backup + Encrypt/ Decrypt & count++ These were sealed inside of Trusted Environment Public Key LINE Client User PIN Data
Secure Software Development on the Server Side Trusted Execution Environment (Isolated servers) Company Network LINE Client LINE Server Backup server Encrypted Backup Internet User PIN Public Key Private Key Backup Data Attempt counts Extended storage
& Restoration Process Extended storage (Persistent) Attempt counts Encrypted Backup + Encrypt/ Decrypt & count++ Request backup or restore Public Key LINE Client User PIN Data
& Restoration Process Extended storage (Persistent) Attempt counts Encrypted Backup + Encrypt/ Decrypt & count++ Retrieve sealed data containing backup & attempt count Request backup or restore Public Key LINE Client User PIN Data
& Restoration Process Extended storage (Persistent) Attempt counts Encrypted Backup + Encrypt/ Decrypt & count++ Execute only when condition meets Retrieve sealed data containing backup & attempt count Request backup or restore Public Key LINE Client User PIN Data Send sealed data containing backup & count
& Restoration Process Extended storage (Persistent) Attempt counts Encrypted Backup + Encrypt/ Decrypt & count++ Execute only when condition meets Store sealed data where backup data and count are updated Request backup or restore Public Key LINE Client User PIN Data
& Restoration Process Extended storage (Persistent) Attempt counts Encrypted Backup + Encrypt/ Decrypt & count++ Execute only when condition meets Store sealed data where backup data and count are updated Result is returned Public Key LINE Client User PIN Data
& Restoration Process Extended storage (Persistent) Attempt counts Encrypted Backup + Encrypt/ Decrypt & count++ Retrieve sealed data containing backup & attempt count Request backup or restore Public Key LINE Client User PIN Data Send sealed data containing backup & count Execute only when given count is equal or larger than TEE’s count
brute-forcing backup PIN Extended storage (Persistent) Attempt counts Encrypted Backup + Encrypt/ Decrypt & count++ Brute-forcing on client app increases counts ✕ Permanently locked when max limit is reached Public Key User PIN Data
brute-forcing backup PIN Extended storage (Persistent) Attempt counts Encrypted Backup + Encrypt/ Decrypt & count++ Company Network Replay attack inside of company network Rejected based on attempt count condition ✕ Public Key User PIN
and monitoring in extended storage - Our colleagues might cover this as a session at future events 🙂 2. Mitigating possible count inconsistency between TEE and extended storage - Attempt count resides at both of TEE and extended storage
TEEs does not sync attempt counts 2. Default routing strategy towards TEE - “Sticky” strategy based on user ID - Same account’s attempts are counted in the same TEE server to limit max count LINE Servers Extended storage User PIN All attempts on account A All attempts on account B TEE Servers
TEE’s count - “reference count” of limiting attempts - Extended storage’s count - Required for persistence - Storage failures lead to inconsistencies in attempt counts ✕ 5. Count after failure: N (Increased count is not applied) 2. Count after ops: N+1 4. Failed to store backup & count 1. Given count: N LINE Servers Extended storage TEE Servers 3. Returned count: N+1 User PIN
attempt because storage’s count is smaller than TEE’s count - User’s attempt is aborted even though they entered a correct PIN. 0. Current count: N (Inconsistent) 2. Current count: N+1 3. Rejected by TEE ✕ LINE Servers Extended storage User PIN (Next attempt) 4. Aborted 1. Given count: N
- Based on Kafka + Decaton (LINE’s streaming task proc framework) - No user impact as inconsistency is fixed - Focus on reducing storage failure’s impact 5. Count after retry succeeds: N+1 (consistent) 4. Retry until storage update succeeds LINE Servers Extended storage 2. Count after ops: N+1 1. Given count: N 3. Returned count: N+1 User PIN
impacts - Changing the routing strategy from ‘sticky’ strategy to round-robin - Attempt count starts on the new TEE without inconsistency - Next attempt succeeds while maintaining the proper resistance to brute-forcing 2. TEE #2’s count starts from N Current count: N TEE #1’s count: N+1 0. Rejected by TEE ✕ 1. Retry Returned count: N + 1 LINE Servers Extended storage User PIN (Next attempt)
feature for users - Preventing account takeover - Seamless chat transfer - Our improvements balancing UX and security - New transfer flow based on biometric auth for device-on-hand case - New Letter Sealing key transfer function for device-not-on-hand case झ݀ࢿ ӝࠄਵ۽ठۄ٘ղਊਸࢸݺೞחߑೱ
phishing - Even when user doesn't have the previous device - Better UX using biometric authentication across our features - Applying LINE client’s biometric auth to LINE login for 3rd parties - Broader coverage of message backup & restoration feature - Supporting cross-platform cloud-based chat backup
projects - Dozens of people from various teams have worked for several months - We promise to continue our journey - The journey to keep enhancing feature usability and user data security