מודול Conscrypt מזרז את השיפורים באבטחה ומשפר את האבטחה במכשיר בלי להסתמך על עדכוני OTA. הספרייה משתמשת בקוד Java ובספרייה מקומית כדי לספק את הטמעת ה-TLS ב-Android, וגם חלק גדול מהפונקציונליות הקריפטוגרפית של Android, כמו גנרטורים של מפתחות, צפנים ותקצירי הודעות. Conscrypt זמין בתור ספרייה בקוד פתוח, אבל יש לו כמה התמחויות כשהוא נכלל בפלטפורמת Android.
המודול Conscrypt משתמש ב-BoringSSL, ספרייה מקומית שהיא פורק (fork) של OpenSSL ב-Google, שמשמשת במוצרים רבים של Google לקריפטוגרפיה ול-TLS (במיוחד ב-Google Chrome), בשילוב עם קוד Conscrypt (גם ב-Java וגם בקוד מקומי). ל-BoringSSL אין גרסאות רשמיות (כל המשתמשים מבצעים build מהקוד המקור), ואין ערובה ליציבות של ה-API או ה-ABI.
שינויים ב-Android 15
ב-Android 15 יש הגבלה על השימוש ב-TLS בגרסאות 1.0 ו-1.1. הגרסאות האלה הוצאו משימוש ב-Android, אבל עכשיו אסור להשתמש בהן באפליקציות שמטרגטות את Android 15.
שינויים ב-Android 14
ב-Android 14 מוצג מאגר אמון ברמה הבסיסית שניתן לעדכון ב-Conscrypt. אישורי CA (או אישורים) מספקים את שורשי האמון למפתחות ציבוריים שמשמשים ב-Android ובאינטרנט באופן כללי. האישורים האלה נבדקים באופן שוטף כדי לוודא שהם חתומים בצורה קריפטוגרפית תקינה, ולכן צריך לספק אותם ולאחסן אותם בכל המכשירים שמסתמכים עליהם.
לפני Mainline, אישורי Android אוחסנו במחיצה של המערכת (ב-system/ca-certificates
) והם עודכנו בכל גרסה של Android. עכשיו, ב-Mainline, אפשר לעדכן את האישורים בתדירות גבוהה יותר באמצעות עדכוני הרכבות של Mainline. היכולת החדשה הזו אמורה לייעל את תהליכי העדכון, לאפשר לנו לפתור בעיות מהר יותר ולעזור להאריך את משך החיים של המכשירים.
החל מגרסה 14 של Android, אישורי בסיס למהימנות מאוחסנים במודול APEX של Conscrypt ובמחיצה של המערכת. אפליקציות עדיין יכולות לבחור אישורים משלהם ולשנות את התנהגות האישור באמצעות NetworkSecurityConfig
.
ב-Android 14 יש גם את השינויים הבאים במודול Conscrypt:
- נוספה הטמעת MAC של AES-CMAC.
- הטמעות MAC מסוג 'PBEwithHmacSHA2-*' הוצאו משימוש והוסרו.
- נוספה תמיכה מוגבלת במפתחות X25519, בהסכמי מפתחות ובחתימות.
- עדכון של BoringSSL לתיקון שגיאות ב-X.509.
- הוסרה התמיכה באישורים בחתימה MD5 בממשקי ה-API הציבוריים של CertPath. אישורים כאלה לא מתקבלים לחיבורי TLS מאז רמת API 16.
שינויים ב-Android 10
מערכת Android 9 לא כוללת ממשק API ציבורי ספציפי ל-Android עבור Conscrypt, אלא משתמשת בספק אבטחה שמטמיע כיתות רגילות של Java Cryptography Architecture (JCA), כולל Cipher ו-MessageDigest, ושל Java Secure Socket Extension (JSSE), כולל SSLSocket ו-SSLEngine.
המשתמשים יוצרים אינטראקציה עם הכיתות האלה, וחלק מממשקי ה-API של Conscrypt שאינם ציבוריים משמשים את libcore
או את הקוד של המסגרות.
ב-Android 10 נוספו מספר קטן של שיטות API ציבוריות ב-android.net.ssl
כדי לגשת לפונקציונליות של Conscrypt שלא נחשפת על ידי הכיתות ב-javax.net.ssl
. Android 10 כולל גם עותק מצומצם של Bouncy Castle כדי לספק כלים קריפטוגרפיים פחות פופולריים כחלק מ-Android Runtime (לא נכלל במודול Conscrypt).
פורמט ויחסי תלות
המודול Conscrypt (com.android.conscrypt
) מופץ כקובץ APEX שכולל את קוד ה-Java של Conscrypt וספרייה מקומית של Conscrypt שמקשרת באופן דינמי לספריות Android NDK (כמו liblog
). הספרייה המקומית כוללת גם עותק של BoringSSL שעבר אימות (אישור מס' 3753) באמצעות התוכנית לאימות מודולים קריפטוגרפיים (CMVP) של NIST.
המודול Conscrypt חושף את ממשקי ה-API הבאים:
- ממשקי API ציבוריים הם תוספים של כיתות וממשקים בחבילות שמתחילות ב-
java.*
וב-javax.*
, וגם של כיתות שמתחילות ב-android.net.ssl.*
. קוד האפליקציה החיצונית לא קורא ל-Conscrypt ישירות. סטנדרטים של ממשקי API בפלטפורמה מבטיחים שה-API האלה יהיו תואמים לאחור ולעתיד. - ממשקי API של פלטפורמת הליבה הם ממשקי API מוסתרים שבהם המערכת משתמשת כדי לגשת לפונקציונליות לא ציבורית. היקף השימוש בהם מוגבל יחסית. המשתמש הגדול ביותר הוא
NetworkSecurityConfig
, שמרחיב את מנהל האמון של Conscrypt (הרכיב שמאמת אישורים) כדי להטמיע את התכונה של הגדרת אבטחת הרשת. - ממשקי API בתוך הליבה מוגבלים למבנים של ברירת מחדל ללא ארגומנטים, שנקראים באופן רפלקטיבי על ידי המכונות של JCA ו-JSEE.