הגדרה של אבטחת רשת

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

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

הוספת קובץ תצורה של אבטחת רשת

התכונה 'הגדרת אבטחת רשת' משתמשת בקובץ XML שבו מציינים את ההגדרות של האפליקציה. צריך לכלול רשומה במניפסט של האפליקציה כדי להפנות לקובץ הזה. קטע הקוד הבא מתוך קובץ מניפסט מדגים איך ליצור את הרשומה הזו: 

<?xml version="1.0" encoding="utf-8"?>
<manifest ... >
    <application android:networkSecurityConfig="@xml/network_security_config"
                    ... >
        ...
    </application>
</manifest>

התאמה אישית של רשויות אישורים מהימנות

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

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

כברירת מחדל, חיבורים מאובטחים (באמצעות פרוטוקולים כמו TLS ו-HTTPS) מכל האפליקציות נסמכים על רשויות אישורים (CA) של המערכת שהותקנו מראש, ואפליקציות שמטרגטות ל-Android 6.0 (רמת API ‏23) ומטה נסמכות גם על מאגר רשויות האישורים שנוספו על ידי המשתמש כברירת מחדל. אפשר להתאים אישית את החיבורים של האפליקציה באמצעות base-config (להתאמה אישית של האפליקציה כולה) או domain-config (להתאמה אישית לכל דומיין).

הגדרה של רשות אישורים (CA) בהתאמה אישית

יכול להיות שתרצו להתחבר למארח שמשתמש באישור SSL בחתימה עצמית או למארח שאישור ה-SSL שלו הונפק על ידי רשות אישורים לא ציבורית שאתם סומכים עליה, כמו רשות האישורים הפנימית של החברה שלכם. קטע הקוד הבא מראה איך להגדיר באפליקציה אישור CA מותאם אישית ב-res/xml/network_security_config.xml: 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">example.com</domain>
        <trust-anchors>
            <certificates src="@raw/my_ca"/>
        </trust-anchors>
    </domain-config>
</network-security-config>

מוסיפים את האישור בחתימה עצמית או אישור CA לא ציבורי בפורמט PEM או DER אל res/raw/my_ca.

הגבלת קבוצת אישורי ה-CA המהימנים

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

ההגדרה להגבלת קבוצת רשויות ה-CA המהימנות דומה להגדרת רשות CA מותאמת אישית כמהימנה עבור דומיין ספציפי, אלא שבמקרה הזה מסופקות כמה רשויות CA במשאב. קטע הקוד הבא מראה איך להגביל את קבוצת רשויות האישורים המהימנות של האפליקציה ב-res/xml/network_security_config.xml: 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">secure.example.com</domain>
        <domain includeSubdomains="true">cdn.example.com</domain>
        <trust-anchors>
            <certificates src="@raw/trusted_roots"/>
        </trust-anchors>
    </domain-config>
</network-security-config>

מוסיפים את רשויות האישורים המהימנות בפורמט PEM או DER אל res/raw/trusted_roots. שימו לב: אם אתם משתמשים בפורמט PEM, הקובץ צריך להכיל רק נתוני PEM, ולא טקסט נוסף. אפשר גם לספק כמה רכיבי <certificates> במקום אחד.

הוספת רשויות אישורים מהימנות

יכול להיות שתרצו שהאפליקציה תסמוך על רשויות אישורים נוספות שהמערכת לא סומכת עליהן, למשל אם המערכת עדיין לא כוללת את רשות האישורים או אם רשות האישורים לא עומדת בדרישות להכללה במערכת Android. אפשר לציין כמה מקורות אישורים להגדרה ב-res/xml/network_security_config.xml באמצעות קוד כמו בדוגמה הבאה. 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config>
        <trust-anchors>
            <certificates src="@raw/extracas"/>
            <certificates src="system"/>
        </trust-anchors>
    </base-config>
</network-security-config>

הגדרת רשויות אישורים לניפוי באגים

כשמבצעים ניפוי באגים באפליקציה שמתחברת באמצעות HTTPS, יכול להיות שתרצו להתחבר לשרת פיתוח מקומי שאין לו אישור SSL לשרת הייצור. כדי לתמוך בזה בלי לבצע שינויים בקוד של האפליקציה, אפשר לציין רשויות אישורים (CA) לניפוי באגים בלבד, שהן מהימנות רק כש-android:debuggable הוא true, באמצעות debug-overrides. בדרך כלל, סביבות פיתוח משולבות (IDE) וכלי בנייה מגדירים את הדגל הזה באופן אוטומטי לגרסאות build שאינן גרסאות הפצה.

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

הקטע הבא מראה איך מציינים רשויות אישורים שמשמשות רק לניפוי באגים ב-res/xml/network_security_config.xml: 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <debug-overrides>
        <trust-anchors>
            <certificates src="@raw/debug_cas"/>
        </trust-anchors>
    </debug-overrides>
</network-security-config>

הצטרפות לשקיפות אישורים

הערה: התמיכה בשקיפות של אישורים זמינה רק מ-Android 16 (רמת API‏ 36).

שקיפות אישורים (CT, ‏ RFC 6962) היא תקן אינטרנט שנועד לשפר את האבטחה של אישורים דיגיטליים. היא מחייבת את רשויות האישורים לשלוח את כל האישורים שהן מנפיקות ליומן ציבורי שמתעד אותם, וכך מגבירה את השקיפות והאחריות בתהליך הנפקת האישורים.

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

כברירת מחדל, האישורים מתקבלים בלי קשר לשאלה אם הם נשמרו ביומן שקיפות אישורים. כדי לוודא שהאפליקציה מתחברת רק ליעדים עם אישורים שמתועדים ביומן CT, אתם יכולים להפעיל את התכונה באופן גלובלי או לכל דומיין בנפרד.

תעבורת נתונים בטקסט לא מוצפן

מפתחים יכולים להביע הסכמה או לבטל הסכמה לתעבורת נתונים בטקסט לא מוצפן (באמצעות פרוטוקול HTTP לא מוצפן במקום HTTPS) באפליקציות שלהם. פרטים נוספים מופיעים במאמר NetworkSecurityPolicy.isCleartextTrafficPermitted().

התנהגות ברירת המחדל של תנועה בטקסט גלוי תלויה ברמת ה-API:

ביטול הסכמה לתעבורת טקסט לא מוצפן

הערה: ההנחיות שבקטע הזה רלוונטיות רק לאפליקציות שמטרגטות Android 8.1 (רמת API 27) או גרסאות קודמות.

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

לדוגמה, יכול להיות שתרצו שהאפליקציה שלכם תוודא שהחיבורים אל secure.example.com תמיד מתבצעים באמצעות HTTPS כדי להגן על תעבורה רגישה מפני רשתות עוינות. 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">secure.example.com</domain>
    </domain-config>
</network-security-config>

הצטרפות לאפשרות של תעבורת נתונים בטקסט גלוי

הערה: ההנחיות שבקטע הזה רלוונטיות רק לאפליקציות שמטרגטות Android 9 (רמת API‏ 28) ומעלה.

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

לדוגמה, יכול להיות שתרצו לאפשר לאפליקציה ליצור חיבורים לא מאובטחים אל insecure.example.com. 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true">insecure.example.com</domain>
    </domain-config>
</network-security-config>

אם האפליקציה צריכה להצטרף לתעבורת נתונים לא מוצפנת לכל דומיין, צריך להגדיר את הערך cleartextTrafficPermitted="true" ב-base-config. חשוב לדעת שמומלץ להימנע מהגדרה לא מאובטחת כזו ככל האפשר. 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="true">
    </base-config>
</network-security-config>

הצמדת אישורים

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

כדי להצמיד אישורים, צריך לספק קבוצה של אישורים לפי הגיבוב של המפתח הציבורי (SubjectPublicKeyInfo של אישור X.509). שרשרת אישורים תקפה רק אם היא מכילה לפחות אחד מהמפתחות הציבוריים המוצמדים.

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

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

בדוגמה הבאה אפשר לראות איך מצמידים אישורים ב-res/xml/network_security_config.xml: 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">example.com</domain>
        <pin-set expiration="2018-01-01">
            <pin digest="SHA-256">7HIpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhJ3Y=</pin>
            <!-- backup pin -->
            <pin digest="SHA-256">fwza0LRMXouZHRC8Ei+4PyuldPDcf3UKgO/04cDM1oE=</pin>
        </pin-set>
    </domain-config>
</network-security-config>

התנהגות של ירושת הגדרות

ערכים שלא מוגדרים בהגדרה ספציפית עוברים בירושה. ההתנהגות הזו מאפשרת הגדרות מורכבות יותר, תוך שמירה על קובץ ההגדרות קריא.

לדוגמה, ערכים שלא מוגדרים ב-domain-config נלקחים מהרכיב ההורה domain-config, אם הם מוטמעים, או מהרכיב base-config, אם לא. ערכים שלא מוגדרים ב-base-config משתמשים בערכי ברירת המחדל של הפלטפורמה.

לדוגמה, נניח שכל החיבורים לתת-דומיינים של example.com צריכים להשתמש בקבוצה מותאמת אישית של רשויות אישורים. בנוסף, תעבורת נתונים שאינה מוצפנת לדומיינים האלה מותרת אלא אם מתחברים אל secure.example.com. אם מקננים את ההגדרה של secure.example.com בתוך ההגדרה של example.com, לא צריך לשכפל את trust-anchors.

הקטע הבא מראה איך הקינון הזה ייראה ב-res/xml/network_security_config.xml: 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">example.com</domain>
        <trust-anchors>
            <certificates src="@raw/my_ca"/>
        </trust-anchors>
        <domain-config cleartextTrafficPermitted="false">
            <domain includeSubdomains="true">secure.example.com</domain>
        </domain-config>
    </domain-config>
</network-security-config>

הגדרת localhost

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

מגרסה Android 17 (רמת API‏ 37) ואילך, אם לא הוגדרה תצורה עבור localhost, נכללת תצורה משתמעת. כברירת מחדל, ההגדרה הזו מבצעת את הפעולות הבאות:

  • מאפשר תנועה שאינה מוצפנת.
  • לא אוכפת שקיפות אישורים (CT).
  • לא אוכף הצמדת אישורים.
  • ההרשאות מוקצות ל-<base-config> עבור נקודות מהימנות.

הגדרה נחשבת כמטרגטת את localhost אם הדומיין הוא:

  • localhost
  • ip6-localhost או
  • כתובת IP מספרית ו-InetAddress.isLoopback() היא true (לדוגמה, 127.0.0.1 או [::1])

פורמט של קובץ תצורה

התכונה 'הגדרת אבטחת רשת' משתמשת בפורמט קובץ XML. מבנה הקובץ מוצג בדוגמת הקוד הבאה: 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config>
        <trust-anchors>
            <certificates src="..."/>
            ...
        </trust-anchors>
    </base-config>

    <domain-config>
        <domain>android.com</domain>
        ...
        <trust-anchors>
            <certificates src="..."/>
            ...
        </trust-anchors>
        <pin-set>
            <pin digest="...">...</pin>
            ...
        </pin-set>
    </domain-config>
    ...
    <debug-overrides>
        <trust-anchors>
            <certificates src="..."/>
            ...
        </trust-anchors>
    </debug-overrides>
</network-security-config>

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

<network-security-config>

יכול להכיל:
0 או 1 מתוך <base-config>
כל מספר של <domain-config>
0 או 1 מתוך <debug-overrides>

<base-config>

תחביר: 
<base-config cleartextTrafficPermitted=["true" | "false"]>
    ...
</base-config>
יכול להכיל:
<trust-anchors> <certificateTransparency>
תיאור:
ההגדרה שמוגדרת כברירת מחדל לכל החיבורים שהיעד שלהם לא נכלל ב-domain-config.

אם לא תגדירו ערכים, המערכת תשתמש בערכי ברירת המחדל של הפלטפורמה.

הגדרת ברירת המחדל לאפליקציות שמטרגטות ל-Android 9 (רמת API‏ 28) ומעלה היא כדלקמן: 

<base-config cleartextTrafficPermitted="false">
    <trust-anchors>
        <certificates src="system" />
    </trust-anchors>
</base-config>

הגדרת ברירת המחדל לאפליקציות שמטרגטות Android 7.0 (רמת API‏ 24) עד Android 8.1 (רמת API‏ 27) היא כדלקמן: 

<base-config cleartextTrafficPermitted="true">
    <trust-anchors>
        <certificates src="system" />
    </trust-anchors>
</base-config>

הגדרת ברירת המחדל לאפליקציות שמיועדות ל-Android 6.0 (רמת API‏ 23) ולגרסאות קודמות היא כדלקמן: 

<base-config cleartextTrafficPermitted="true">
    <trust-anchors>
        <certificates src="system" />
        <certificates src="user" />
    </trust-anchors>
</base-config>

<domain-config>

תחביר:
<domain-config cleartextTrafficPermitted=["true" | "false"]>
    ...
</domain-config>
יכול להכיל:
‫1 או יותר <domain>
‫0 או 1 <certificateTransparency>
‫0 או 1 <trust-anchors>
‫0 או 1 <pin-set>
כל מספר של <domain-config>
מקוננים
תיאור:
ההגדרה שמשמשת לחיבורים ליעדים ספציפיים, כפי שמוגדרים ברכיבי domain.

שימו לב: אם כמה רכיבי domain-config חלים על יעד מסוים, המערכת משתמשת בהגדרה עם כלל הדומיין הספציפי ביותר (הארוך ביותר) שתואם ליעד.

<domain>

תחביר: 
<domain includeSubdomains=["true" | "false"]>example.com</domain>
מאפיינים:
includeSubdomains
אם "true", כלומר אם הדומיין הזה הוא דומיין ברמה העליונה, כלל הדומיין הזה תואם לדומיין ולכל תתי-הדומיין שלו, כולל תתי-דומיין של תתי-דומיין. אחרת, הכלל חל רק על התאמות מדויקות.

<certificateTransparency>

תחביר:
<certificateTransparency enabled=["true" | "false"]/>
תיאור:
אם true, האפליקציה תשתמש ביומני שקיפות האישורים כדי לאמת את האישורים. כשמשתמשים באפליקציה באישור משלה (או בחנות המשתמש), סביר להניח שהאישור לא ציבורי ולכן לא ניתן לאמת אותו באמצעות שקיפות האישורים. כברירת מחדל, האימות מושבת במקרים האלה. עדיין אפשר לכפות את האימות באמצעות <certificateTransparency enabled="true"/> בהגדרות הדומיין. לכל <domain-config>, ההערכה מתבצעת לפי הסדר הבא:
  1. אם certificateTransparency מופעל, מפעילים את האימות.
  2. אם הערך של <trust-anchors> הוא "user" או מוטבע (כלומר, "@raw/cert.pem"), משביתים את האימות.
  3. אחרת, מסתמכים על ההגדרה שעברה בירושה.

<debug-overrides>

תחביר: 
<debug-overrides>
    ...
</debug-overrides>
יכול להכיל:
0 או 1 <trust-anchors>
תיאור:
החלפת ברירת המחדל שתחול כשהערך של android:debuggable הוא "true", שזה בדרך כלל המצב בגרסאות build שאינן גרסאות הפצה שנוצרות על ידי סביבות פיתוח משולבות (IDE) וכלים לבניית אפליקציות. ישויות עוגן אמינות שצוינו ב-debug-overrides נוספות לכל שאר ההגדרות, ולא מתבצעת הצמדת אישורים כשרשרת האישורים של השרת משתמשת באחת מישויות העוגן האמינות האלה לניפוי באגים בלבד. אם הערך של android:debuggable הוא "false", המערכת מתעלמת לגמרי מהקטע הזה.

<trust-anchors>

תחביר: 
<trust-anchors>
...
</trust-anchors>
יכול להכיל:
Any number of <certificates>
תיאור:
קבוצה של נקודות מהימנות לחיבורים מאובטחים.

<certificates>

תחביר:
<certificates src=["system" | "user" | "raw resource"]
              overridePins=["true" | "false"] />
תיאור:
קבוצה של אישורי X.509 לרכיבי trust-anchors.
מאפיינים:
src
המקור של אישורי CA. כל אישור יכול להיות אחד מהסוגים הבאים:
  • מזהה משאב גולמי שמפנה לקובץ שמכיל אישורי X.509. האישורים צריכים להיות מקודדים בפורמט DER או PEM. במקרה של אישורי PEM, הקובץ לא יכול להכיל נתונים נוספים שאינם PEM, כמו הערות.
  • ‫"system" לאישורי CA של המערכת שמותקנים מראש
  • ‫"user" לאישורי CA שנוספו על ידי משתמשים
overridePins

המדיניות הזו קובעת אם רשויות האישורים מהמקור הזה יעקפו את הצמדת האישורים. אם "true", אז הצמדה לא מתבצעת בשרשראות אישורים שנחתמו על ידי אחת מרשויות האישורים מהמקור הזה. האפשרות הזו יכולה להיות שימושית לניפוי באגים של רשויות אישורים או לבדיקת התקפות אדם בתווך על תנועה מאובטחת של האפליקציה.

ערך ברירת המחדל הוא "false", אלא אם מציינים ערך אחר ברכיב debug-overrides, ובמקרה כזה ערך ברירת המחדל הוא "true".

<pin-set>

תחביר: 
<pin-set expiration="date">
...
</pin-set>
יכול להכיל:
Any number of <pin>
תיאור:
קבוצה של הצמדות של מפתחות ציבוריים. כדי שחיבור מאובטח ייחשב למהימן, אחד מהמפתחות הציבוריים בשרשרת האמון צריך להיות בקבוצת הפינים. בכתובת <pin> מפורט הפורמט של הפינים.
מאפיינים:
expiration
התאריך, בפורמט yyyy-MM-dd, שבו הפינים יפוגו, וכך יושבת הקיבוע. אם המאפיין לא מוגדר, התוקף של קודי האימות לא יפוג.

תפוגה עוזרת למנוע בעיות בקישוריות באפליקציות שלא מקבלות עדכונים של מערך הפינים, למשל כשהמשתמש משבית את העדכונים של האפליקציה.

<pin>

תחביר: 
<pin digest=["SHA-256"]>base64 encoded digest of X.509
    SubjectPublicKeyInfo (SPKI)</pin>
מאפיינים:
digest
אלגוריתם הגיבוב ששימש ליצירת ה-pin. בשלב הזה יש תמיכה רק ב-"SHA-256".