הנקודה היא בכלל שבפיתוח נורמלי של קוד הצפנה,אין להרשות לכתוב
למה בכלל הגורם העויין צריך לשבור את הראש אם יש לו את הקוד?
אם יש לו את מספר ה-....... אז הוא לא צריך בכלל לשבור את הראש אלא רק להשתמש עם מספר ה-.......... במקום הנכון והכל פתוח בפניו.
ואם אין לו את מספר ה-........... אז הוא צריך רק לנסות כל צרוף אפשרי והאמת היא שאין הרבה אפשרויות של צירופים אפשריים מאחר והתוכנה עצמה (משנת 1996 במקור) בנויה כך שמספר האפשרויות הוא נמוך ביותר.
מאז 1996 שכל התקשורות לשב"א היו אז רק דרך קו הטלפון של בזק והיו רק שתי חברות אשראי בישראל, בוצעו עידכוני תוכנה טלאי על טלאי על מנת להתאים את התוכנה למצבים המשתנים, אבל התוכנה נשארה למעשה עם אותן מגבלות של שנת 1996.
יתכן ועם המעבר לתוכנת אשראית EMV החדשה הבעיה תיפטר, אבל אני לא רואה את זה קורה בקרוב.
יש כיום מעט בתי עסק בישראל שעובדים עם תוכנת EMV החדשה והרוב ממשיכים עדיין לעבוד עם התוכנה המיושנת משנת 1996. בנק ישראל מאריך כל פעם מחדש את החובה לעבור לתוכנת EMV החדשה שהיא בטוחה הרבה יותר והגישה למידע שם היא יותר מורכבת.
אבל שלא תחשוב חלילה שתוכנת ה-EMV היא מושלמת לחלוטין. גם בה נמצאים קבצים בפורמט טקסט הקריא לאדם.
ובאופן כללי, רמת האבטחה וההצפנה של היצרנים הפרטיים (כמו וריפון וכספיט) היא גבוהה הרבה יותר מהרמה של גירסאות אשראית הסטנדרטיות ל-PC.
הנקודה היא בכלל שבפיתוח נורמלי של קוד הצפנה,אין להרשות לכתוב
קוד בצורה שמשתמש קצה יוכל כלל להגיע לאותו מאסטר קוד, הדבר היה אמור להיות מוהאש בצורה שאף אחד (!) לא ישתמש בקוד ראשי, אלא רק בקודי משנה הנותנים הרשאה לקבל רק את הנתונים שהלקוח צריך בלבד
ולגבי תקן EMV זה בכלל סיפור אחר, אם אתה יודע טוב את מערך הסטנדרט ISO7816, ידוע לך שבחלק 4 נומק אופן תמסורת APDU שלרוב זהה לכל אפליקציה הכלולה בכרטיס חכם.
שירותי ההצפנה וקריפטוגרפיה מייושמים ברמת הייצוג והאפליקציה, ועדיין אם הנתונים מוהאשים כראוי, רק גורם מסויים יכול לבצע קצת יותר דברים מכל משתמש אחר
נקח את הרב-קו לדוגמא כדי להחזיר את הנושא למקום הנכון אחרי כל האופטופ בנושא אבטחת מידע: לקרוא את החלק הציבורי (!) של האפליקציה השמורה בכרטיס, יכול כל דבר אשר ייושם כראוי (הופאון, רב-קו אונליין, אפליקציות אחרות, Cardpeek, ועוד)
אך לכתוב חוזים יכול רק לקוח המזדהה אל הכרטיס באמצעות קוד SAM המיועד לכתיבת נתונים, (קובץ תקן ציבורי מצורף, פרק 4.2, ופרק 6) וסעיפיו
האפליקציה אומנם מזדהה על ידי input מסויים, , והכרטיס מוודא שהמפתח תקין לפני שהוא מאפשר לכתוב חוזה
בפרק 6.2.3 נומק שהמפתח DESX שמור כ-3DES עם דיברסיפיקציה, ומספר אופני האשינג MAC
כך שכל מה שהלקוח יכול לקבל בלוגים למעט קוד תמסורת APDU בשכבה תחתונה, זה רק ההאש של המפתח הכרטיס בלבד, והלקןח לא יוכל להסב את זה למקור
סוגי מפתחות המיועדים לרמת גישה שונה מפורטים בפרק 6.4 , כתיבה מתבצעת ברמת Session , מזוהה על ידי מפתח הכתיבה (ואל הכרטיס והאפליקציית הקצה מועבר רק האש של מידע שהאימות בוצע בהצלחה, ללקוח אין אפשרות לקבל את מפתח SAM המקור), מוחתם, מאושר ועובר רטיפיקציה
