מה זה Tink?

Tink היא ספריית קריפטוגרפיה בקוד פתוח שנכתבה על ידי קריפטוגרפיה מהנדסי אבטחה ב-Google. ממשקי ה-API המאובטחים והפשוטים של Tink מפחיתים את הסיכון המלכודות בעיצוב שמתמקד במשתמש, הטמעה קפדנית ובדיקות קוד, ובדיקות מקיפות. בקטע יעדים בדף הזה מוסבר איך לקבל יותר תובנות על המטרות שטינק נועד למלא.

Tink עוזר למשתמשים ללא רקע קריפטוגרפי להטמיע באופן בטוח למשימות קריפטוגרפיות. ב-Google, שירות Tink נפרס במאות מוצרים ומערכות.

למה כדאי להשתמש ב-Tink?

הסיבות החשובות ביותר לשימוש ב-Tink הן:

• קל לשימוש

  קשה להגדיר את הקריפטוגרפיה בצורה נכונה. עם Tink, אפשר להצפין או לחתום על הנתונים באמצעות אבטחה מובנית באמצעות כמה שורות קוד בלבד. Tink יכול גם לעזור לך לבצע רוטציה של מפתחות או מפתחות מאובטחים באמצעות מערכות חיצוניות לניהול מפתחות (KMS).

• זה מאובטח

  ב-Tink מוסיפים אמצעי אבטחה לספריות מוכרות כמו BoringSSL. וארכיטקטורת קריפטוגרפיה של Java ומציגה אותם ישירות בממשקים, כדי שהבודקים והכלים יוכלו לאתר פערים במהירות. Tink מפריד גם בין ממשקי API שעלולים להיות מסוכנים, לכן תוכלו לעקוב אחריהם.

• האפליקציה תואמת

  טקסטים מוצפנים (ciphertext) של Tink תואמים לספריות הקריפטוגרפיה הקיימות. טינק תומכת גם בהצפנה או אחסון של מפתחות Amazon KMS, Google Cloud KMS, Android Keystore ו-iOS Keychain.

מי משתמש ב-Tink?

חברות רבות, כולל Google, Square ו-Citadel, נמצאות בשימוש נרחב ב-Tink, וגם מאות לקוחות של Google Cloud ושותפים של Google Pay. טינק גם שמפעיל את ספריית האבטחה של Jetpack, שמאבטחת הרבה אפליקציות פופולריות ל-Android כמו Slack, Adidas, AirBnb ו-Nextdoor.

מטרות עסקיות קטנות

מהן המטרות העיקריות של Tink בהשוואה לספריות קריפטוגרפיות אחרות, וגם מהם המנגנונים העיקריים ש-Tink משתמש בהם כדי להשיג את היעדים האלה?

בקיצור, ל-Tink יש שני יעדים:

1. קידום גמישות קריפטוגרפית: המשתמשים צריכים להיות מסוגלים לשנות מפתחות בצורה פשוטה.
2. הפעלת בדיקות אבטחה: מטרת Tink היא לאפשר למשתמשים לכתוב קוד ניתן לבדוק באופן מקומי את האבטחה, באמצעות ממשקים שמספקים ואחריות אבטחה.

אלה המנגנונים העיקריים ש-Tink משתמש בהם כדי להשיג את היעדים האלה:

1. Tink מספק פרימיטיביים וממשקים כהפשטות חשובות. האלה הפשטה של נתונים מאפשרת למשתמשים לכתוב קוד שלא מציין שיש להשתמש בו, אך במקום זאת מציין את תפיסת האבטחה הצפויה.
2. Tink משתמש במושג 'קבוצת מפתחות', שהיא קבוצה של מפתחות שמשויכים לפרימיטיבי מסוים. התוצאה היא שמשתמשים כותבים קוד שפועל עם כמה מפתחות.
3. ב-Tink, המפתחות לא מצוינים רק על ידי חומר המפתח הבסיסי, אלא גם את האלגוריתם הקריפטוגרפי וגם את כל הפרמטרים. המשמעות היא מפתח Tink תמיד בוחר פונקציה קריפטוגרפית ייחודית מכל אפשרות יכולות להתקיים ולא משאירות מקום לפרשנות.

בחלקים הבאים נסביר את העקרונות האלה בפירוט.

גמישות קריפטוגרפית

כדאי לשקול את הנדסת תוכנה ב-Google, ספר על שיעורים שנלמדו בתחום הנדסת התוכנה, כתובית "שיעורים שנלמדו מהתכנות עם הזמן". בו, המחברים מאמצים רבים כדי לשקף את ההשלכות של העובדה שדברים משתנים. הזה גם השפיעו על חלק גדול מהעיצוב של Tink. בתחום הקריפטוגרפיה חשוב שמתכוננים לשינוי. המפתחות ידלפו והאלגוריתמים ייכשלו. היכולת להוציא מפתחות ואלגוריתמים חיונית למשתמשים רבים. להיות מושכלים.

ביקורות אבטחה ונכסים מקומיים

Tink מקדם את השימוש בממשקים, כמו ממשק AEAD שלנו, שמאפשר למשתמשים להצפין את הנתונים. בין אחריות אבטחה אחרת, מסמך AEAD מבטיח שכמה הצפנות של אותה מחרוזת מובילות מידע מוצפן (ciphertexts).

כדי לראות כיצד ניתן להשתמש בזה, נניח שמהנדס רוצה לאחסן נתונים המזהה בקובץ Cookie של משתמש. הם עשויים להציג מחלקה כמו זו:

class IdEncrypter {
  public static IdEncrypter createFromAead(Aead aead);

  public String encrypt(long id) throws GeneralSecurityException;
  public long decrypt(String encrypted) throws GeneralSecurityException;
};

העברת Aead מקבלת את המאפיינים הבאים:

1. הקוד מצהיר שכדי ש-IdEncrypter יבצע את פעולתו, הוא דורש של סכמת ההצפנה עם מאפייני האבטחה שAead מספק. לחלופין, DeterministicAead לא מספיק – לפי הדרישות של IdEncrypter, שתי הצפנה יש שונים. לעומת זאת, לקחת כפרמטר כמופע של הצפנת AES GCM (מופע ספציפי של Aead) יהיה יותר מדי מחמיר: כל Aead מספיק כדי IdEncrypter לבצע את העבודה, צריכים להיות אלגוריתם אחד ספציפי.
2. בדיקת האבטחה יכולה להביא בחשבון את הנקודה הזו. בודק אבטחה עושה לא צריך לעבור על כל מאגר הקודים כדי לבדוק במקום כלשהו, מישהו יצר מחלקה משנית של Aead שאינה מאובטחת לשימוש עם IdEncrypter. במקום זאת, Tink מספק מאפייני אבטחה לאובייקטים של Aead יש, והבודק יכול לבדוק שהם מספיקים.

באופן ספציפי, הנקודה השנייה מחייבת תשומת לב רבה. לעיתים קרובות משתמשים מבקשים להוסיף אלגוריתמים Aead. הנקודה הקודמת ממחישה למה זה מסוכן: אם יש הטמעה זמינה של Aead שעושה לא יספק את התחייבויות האבטחה הנדרשות, IdEncrypter עלול להפוך לבלתי מאובטח, והמהנדס שמבצע בדיקת אבטחה צריך לבחון קוד נוסף כדי לבדוק שהאובייקט נוצר (instantiation) בצורה נכונה.