സുരക്ഷ എങ്ങനെ പ്രവർത്തിക്കുന്നു, ലളിതമായ വാക്കുകളിൽ.

ലളിതമായ വാക്കുകളിൽ

നിങ്ങളുടെ ഓരോ ഉപകരണവും സ്വന്തമായി ഒരു താക്കോൽ ജോടി ഉണ്ടാക്കുന്നു. നിങ്ങൾ ഒരു സന്ദേശം അയക്കുമ്പോൾ, നിങ്ങളുടെ phone അതിനെ ഒരു പുതിയ ഒറ്റത്തവണ താക്കോൽ ഉപയോഗിച്ച് പൂട്ടുന്നു, പിന്നെ ആ താക്കോൽ ചാറ്റിലെ ഓരോ ഉപകരണത്തിനും വെവ്വേറെ പൂട്ടുന്നു. ആ ഉപകരണങ്ങൾക്ക് മാത്രമേ അത് തുറക്കാൻ കഴിയൂ. നിങ്ങളുടെ phone സന്ദേശത്തിൽ ഒരു ഒപ്പും ഇടുന്നു; അതുകൊണ്ട് വായിക്കുന്ന ആളുടെ phone-ന് ഉറപ്പിക്കാൻ കഴിയും — ഇത് ശരിക്കും നിങ്ങളിൽ നിന്ന് വന്നതാണ്, വഴിയിൽ ആരും മാറ്റിയിട്ടില്ല എന്ന്.

സാങ്കേതിക സംഗ്രഹം

• ഉപകരണ താക്കോലുകൾ: താക്കോൽ കൈമാറ്റത്തിന് X25519-ഉം ഒപ്പിടാൻ Ed25519-ഉം, ഉപകരണത്തിൽ തന്നെ നിർമ്മിക്കുന്നു. സ്വകാര്യ താക്കോലുകൾ platform-ന്റെ സുരക്ഷിത സ്ഥലത്ത് സൂക്ഷിക്കുന്നു, ഒരിക്കലും upload ചെയ്യുന്നില്ല.
• സന്ദേശങ്ങൾ: ക്രമരഹിതമായ 256-bit ഉള്ളടക്ക താക്കോൽ ChaCha20-Poly1305 ഉപയോഗിച്ച് ഉള്ളടക്കം സംരക്ഷിക്കുന്നു. ഉള്ളടക്ക താക്കോൽ ഓരോ സ്വീകർത്താവിന്റെ ഉപകരണത്തിനും ephemeral X25519 + HKDF-SHA256 ഉപയോഗിച്ച് പൊതിയുന്നു. envelope header (സംഭാഷണം, അയക്കുന്ന ആൾ, ഉപകരണം, സന്ദേശ id, സ്വീകർത്താക്കളുടെ പട്ടിക) associated data ആയി ബന്ധിപ്പിച്ച് Ed25519 ഉപയോഗിച്ച് ഒപ്പിടുന്നു.
• ഫയലുകൾ: ഒരു ഒറ്റത്തവണ താക്കോൽ ഉപയോഗിച്ച് ഉപകരണത്തിൽ തന്നെ സംരക്ഷിക്കുന്നു; ആ താക്കോൽ സംരക്ഷിക്കപ്പെട്ട സന്ദേശത്തിനുള്ളിൽ കൊണ്ടുപോകുന്നു. സെർവർ സൂക്ഷിക്കുന്നത് സംരക്ഷിക്കപ്പെട്ട ഉള്ളടക്കം മാത്രം.
• കോളുകൾ: DTLS-SRTP media-യോടുകൂടിയ WebRTC. Offers, answers, ICE candidates എന്നിവ ഒപ്പിട്ട്, സംരക്ഷിക്കപ്പെട്ട envelope-കളിലൂടെ സഞ്ചരിക്കുന്നു; അതിനാൽ കോൾ ആരംഭിക്കുന്ന വിവരം സെർവറിന് വായിക്കാനോ കൃത്രിമമായി ഉണ്ടാക്കാനോ കഴിയില്ല.
• സുരക്ഷാ നമ്പറുകൾ: രണ്ട് പേരുടെയും ഉപകരണ താക്കോലുകളുടെ ഒരു മുദ്ര. നേരിൽ കണ്ട് ഒത്തുനോക്കിയാൽ ഇടയ്ക്ക് ആരും ഇല്ല എന്ന് ഉറപ്പിക്കാം. ഒരു contact-ന്റെ താക്കോലുകൾ മാറുമ്പോൾ app മുന്നറിയിപ്പ് നൽകുന്നു.
• സൈൻ-ഇൻ: scrypt password hash, ഐച്ഛികമായ TOTP രണ്ട്-ഘട്ട സ്ഥിരീകരണം hashed recovery codes സഹിതം, 5 തവണ തെറ്റിയാൽ ലോക്ക്-ഔട്ട്, 12 മണിക്കൂർ നിഷ്‌ക്രിയമായാൽ സെഷൻ അവസാനിക്കും, പരമാവധി 24 മണിക്കൂർ സെഷൻ, HttpOnly SameSite=Strict cookie. SMS ഒരിടത്തും ഉപയോഗിക്കുന്നില്ല.
• വെബ്: കർശനമായ Content-Security-Policy, മൂന്നാം കക്ഷി ഉറവിടങ്ങൾ ഇല്ല, ഫ്രെയിം എംബെഡിംഗ് അനുവദിച്ചിട്ടില്ല, പ്രൊഡക്ഷനിൽ HSTS.
• Android: സ്ക്രീൻ പകർത്തലിനെതിരെ FLAG_SECURE, ക്ലിയർടെക്സ്റ്റ് ട്രാഫിക് നിർജ്ജീവമാക്കി, ആപ്പ് ബാക്കപ്പ് നിർജ്ജീവമാക്കി.

സെർവറിന് എന്ത് കാണാൻ കഴിയും

ആര് ആരോട് സംസാരിക്കുന്നു, എപ്പോൾ, സന്ദേശത്തിന്റെയും ഫയലിന്റെയും വലിപ്പം, ഗ്രൂപ്പ് പേരുകളും അംഗത്വവും, ഒരു കോൾ ആരംഭിക്കുന്നു എന്ന വിവരം — ഇവ സെർവറിന് കാണാം. ജോലികൾ, കരാറുകൾ, report കരടുകൾ എന്നിവ end-to-end സംരക്ഷണം ഇല്ലാതെ സെർവറിൽ സൂക്ഷിക്കുന്നു. ഇത് ഞങ്ങൾ സ്വകാര്യത താളിൽ തുറന്ന് പറഞ്ഞിട്ടുണ്ട്.

ഞങ്ങൾ എങ്ങനെ പരിശോധിക്കുന്നു

ഓരോ release-ഉം 40-ലധികം പരിശോധനകൾ ഉൾക്കൊള്ളുന്ന ഒരു യന്ത്രനിർമ്മിത ഗേറ്റ് കടക്കണം. ഇതിൽ ഉൾപ്പെടുന്നവ: Python-ൽ എഴുതിയ, app-മായി പ്രവർത്തിക്കണം എന്ന് നിർബന്ധമുള്ള, protocol-ന്റെ ഒരു സ്വതന്ത്ര നടപ്പാക്കൽ; കൃത്രിമം കാണിച്ച, കള്ളമായ, ആവർത്തിച്ച envelope-കൾക്കെതിരായ ആക്രമണ പരിശോധനകൾ; plaintext-നായി സെർവർ database-ന്റെ ഒരു scan; കാലഹരണപ്പെട്ട disappearing messages അവയുടെ താക്കോലുകൾ സഹിതം മായ്ക്കപ്പെടുന്നു എന്ന് ഉറപ്പാക്കൽ; web app ഒരൊറ്റ മൂന്നാം കക്ഷി request-ഉം ഉണ്ടാക്കുന്നില്ല എന്ന് browser audit.

അറിയപ്പെടുന്ന പരിമിതികൾ

• ഇനിയും forward secrecy ratchet ഇല്ല: ഒരു ഉപകരണ താക്കോൽ മോഷ്ടിക്കപ്പെട്ടാൽ ആ ഉപകരണത്തിന് അയച്ച പഴയ സന്ദേശങ്ങൾ വായിക്കാൻ കഴിഞ്ഞേക്കും. double-ratchet രൂപകൽപ്പന roadmap-ൽ ഉണ്ട്.
• മുകളിൽ വിവരിച്ചതുപോലെ, metadata സെർവറിന് കാണാം.
• ഒരു വെബ് പതിപ്പിന്റെ സുരക്ഷ ബ്രൗസറിനെയും ഞങ്ങളുടെ സെർവർ അയയ്ക്കുന്ന കോഡിനെയും ആശ്രയിച്ചാണിരിക്കുന്നത്. വെബ് പതിപ്പ് ക്ഷണിക്കപ്പെട്ട ചെറിയൊരു കൂട്ടർക്കു മാത്രമായുള്ള പൈലറ്റിൽ ഒതുങ്ങുന്നതിന്റെ ഒരു കാരണം ഇതാണ്: Google Play ആപ്പ് ആദ്യം വരും, അതിന്റെ സൈനിംഗ് സർട്ടിഫിക്കറ്റ് ഞങ്ങൾ Get Namaskara പേജിൽ പ്രസിദ്ധീകരിക്കും.

ഒരു സുരക്ഷാ പ്രശ്നം റിപ്പോർട്ട് ചെയ്യുക

ഒരു vulnerability കണ്ടെത്തിയോ? പ്രസിദ്ധീകരിക്കുന്നതിന് മുൻപ് ദയവായി ഞങ്ങളെ സ്വകാര്യമായി അറിയിക്കൂ — subject-ൽ "Security" എന്ന് ചേർത്ത് Contact വഴി. ഞങ്ങൾ മറുപടി നൽകും, പ്രശ്നം പരിഹരിക്കും, നിങ്ങൾ ആഗ്രഹിക്കുന്നെങ്കിൽ നിങ്ങൾക്ക് നന്ദി പറയും. മറ്റ് ആളുകളുടെ account-കൾക്കെതിരെ പരിശോധന നടത്തരുത്.