SlideShare a Scribd company logo

Positive Hack Days. Sklyarov. Vulnerabilities in the Systems of Authenticity Control of Digital Photographic Images

•Download as PPT, PDF•
•
Positive Hack Days
Positive Hack Days

The report considers practical aspects of reliability of existing systems allowing authentication of photographic evidence originality. The reporter examines a vulnerability in the Canon Original Data Security system of image authenticity verification, which was designed to authenticate originality of images captured by the Canon digital reflex still cameras.

1 of 40
Vulnerabilities in the Systems of Authenticity Control of Digital Photographic Images Positive Hack Days Dmitry Sklyarov
What is Original Decision Data It is too easy to edit photos… ODD is added to the image file by camera and expected to provide information to detect any image alteration Modified!
My first DSLR – Canon EOS 350D Great piece of hardware Like it very much! (honestly! :) Does not support Original Image Verification features :(
My next DSLR – Canon EOS 30D Even better than 350D : ) Custom Function 19: Add Original Decision Data to each picture taken
EOS 30D: ODD in .JPG file ODD is stored as 160 (0xA0) bytes appended after JPEG EOI ( 0xFFD9 ) marker File offset of ODD is stored as 32-bit value in Tag 0x0083 inside EXIF/MakerNote IFD (Image File Directory) .JPG file JPEG SOI (0xFFF8) marker EXIF data JPEG EOI (0xFFF9) marker ODD: 160 (0xA0) bytes JPEG main image EXIF MakerNote IFD (Canon-specific) Tag 0x0083: ODD offset: 32 bits
EOS 30D: ODD dump 0000 : FF FF FF FF 02 00 00 00 59 89 7D ED 86 BE 89 C8 0010 : 68 98 52 0F 4C C2 E0 86 1A BF BA DC 04 00 00 00 0020 : 00 00 00 00 C6 45 00 00 43 1B 0B 00 D6 15 F0 36 0030 : 91 92 21 DC 9B 33 B8 20 C9 C7 F2 EC 04 7C 9E 5B 0040 : 01 00 00 00 00 00 00 00 36 00 00 00 62 99 34 61 0050 : A9 17 AA DB 14 BE 60 0C 20 73 F1 B8 21 DD 6B 90 0060 : 02 00 00 00 3A 00 00 00 02 03 00 00 FC 45 9E 9A 0070 : 8B 1E 7D 26 F0 7C 5D A3 B1 A9 42 17 75 0F 41 0B 0080 : 03 00 00 00 40 03 00 00 86 42 00 00 9B E2 81 AE 0090 : 59 D8 21 6D 0F 9B 15 D0 CA 85 28 D8 44 7F 8F 5D ODD marker ODD version Number of Regions Region IDs Region offsets Region lengths
ODDv2: Regions layout R0: Main Image R1: From 0 to Tag 0x0112 of EXIF Main IFD (Orientation tag) R2: From Orientation tag to ODD Offset tag R3: From ODD Offset tag to Main Image Region 1 EXIF Orientation tag (4 bytes) Region 2 EXIF ODD Offset tag (4 bytes) Region 3 Region 0 (Main Image) ODD (160 bytes)
ODDv2: General structure typedef struct { DWORD marker ; // Marker == ~ 0 DWORD ver; // ODD version == 2 BYTE unknown _1[ 20 ]; DWORD nRegions; // Number of Regions == 4 struct { DWORD id; // Region ID DWORD o; // Region data offset DWORD cb; // Region data length BYTE unknown _2[ 20 ]; } r[4]; // Regions } T_ODD_v2; // sizeof(T_ODD_v2) == 0xA0
ODDv2: Guessing unknown s Field before regions definition Represents signature for the whole image file? Field inside region definition Hold signature of the particular region data? Signature length is always 20 bytes Too short for asymmetric , but matches SHA-1 length Symmetric SHA-1 based authentication? May be HMAC-SHA-1?
Explore CHDK (Canon Hacker's Development Kit) Wiki and forum Dump firmware using “blinking” or some other technique Use IDA Pro to analyze dumped ARM code Looking into camera’s firmware Three easy steps :)
ODDv2: Clarified structure typedef struct { DWORD marker ; // Marker == ~ 0 DWORD ver; // ODD version == 2 BYTE imgHMAC[SHA_DIGEST_LENGTH ]; DWORD nRegions; // Number of Regions == 4 struct { DWORD id; // Region ID DWORD o; // Region data offset DWORD cb; // Region data length BYTE HMAC [ SHA_DIGEST_LENGTH ]; } r[4]; // Regions } T_ODD_v2; // sizeof(T_ODD_v2) == 0xA0
ODDv2: Region HMAC Hash region data bytes with MD5 Repeat 128-bit region hash value 4 times to fill 64-byte buffer Calculate HMAC for the buffer, store result in ODDv2.r[i].HMAC MD5 Region[i] data bytes Rgn[i] hash HMAC-SHA-1 Rgn[i] HMAC HMAC key Rgn[i] hash Rgn[i] hash Rgn[i] hash Rgn[i] hash
ODDv2: Image file HMAC Merge four 1 28-bit hash values for all 4 regions to fill 64-byte buffer Calculate HMAC for the buffer, store result in ODDv2.imgHMAC HMAC-SHA-1 File HMAC HMAC key Rgn[0] hash Rgn[1] hash Rgn[2] hash Rgn[3] hash
ODDv2: What is HMAC key Length is 256 bits (32 bytes) Builds from two 128-bit parts, each part is stored separately in obfuscated form Last 32 bits are replaced by camera’s BodyID (stored in EXIF) before HMAC calculation de-obfuscated Left part (128 bits) de-obfuscated Right part (128 bits) BodyID (32 bits)
ODDv2: Notes on HMAC key Key value is the same for all cameras of some particular model (e.g. EOS 30D) Different camera models (5D, 20D, 30D) uses different keys Knowing key for particular model allows forging ODD for any camera of that model! Key can be extracted from the camera!
EOS 40D: New version of ODD ODD is stored within EXIF ODD version is 3 Image file length is stored inside ODD File is treated as set of areas (based on content type) Area could contain several regions Integrity of each area monitored independently
ODDv3: Area layout in .JPG file Main image All other data Orientation User comment Check marks Thumbnail Area 2 (other) ODD (excluded from Area 2) Area 1 (Main image) Area 3 (Orientation) Area 4 (User comment) Area 6 (Thumbnail) Area 5 (Check marks) Note: ODD is not included in any area Exif data
ODDv3: General structure ODDv3 Header Information Image information Area descriptors Padded with zeros Marker and Version Image file signature ODD Info signature
ODDv3: Header structure typedef struct { DWORD marker ; // Marker == ~ 0 DWORD ver; // ODD version == 3 DWORD cbImg Sig; // len(Sign( Image) ) BYTE i mg Sig [cbImg Sig ]; // Sign (Image ) DWORD cbInfo Sig ; // len(Sign (oddInfo )) BYTE i nfo Sig [cbInfo Sig ]; // Sign (oddInfo) } T_ODDv3_Hdr; Note: cbImg Sig and cbInfo Sig are always == 20 == SHA_DIGEST_LENGTH
ODDv3: Area structure typedef struct { DWORD id; // Area ID DWORD cbSalt ; // Salt length BYTE abSalt[cbSalt];// Salt DWORD cb Sig ; // Len(Sign(Area)) BYTE ab Sig [cb Sig ]; // Sign(Area) DWORD nRange; // Ranges count struct { DWORD o; // Range offset DWORD cb; // Range length } r[nRange]; // Array of r anges } T_ODDv3_Area;
ODDv3: Info part structure typedef struct { DWORD cbInfo; // Length of Info part DWORD cbSigSalt; // Image/oddInfo salt length BYTE s igSalt[cbSigSalt]; // Image/oddInfo salt DWORD v3; // Version again? == 3 DWORD cbFile; // Total size of file DWORD vHash; // 1 : VxWorks, 2 or 3: DryOS DWORD KeyID; // Encryption key ID DWORD BoardID; // Board ID DWORD KeySalt; // HMAC key salt DWORD nArea; // Number of areas follows T_ODDv3_Area[ nArea ]; // Area descriptions BYTE zeros[]; // Zero filling } T_ODDv3_Info;
Ver 2 and 3, OS: DryOS Note: Salt is not used (but still stored in ODD) ODDv3: Hash algorithm version Ver 1, OS: VxWorks SHA-256 Data bytes Result MD5 Data bytes Hash Result PRNG Salt Random1 Random2 MD5 Hash+ Random1 MD5 Hash+ Random 2
Salt values are obtained from weak PRNG Seed value is based on total number of shots taken by camera ( Shutter Counter ) ODD information could be used to discover actual Shutter Counter value! ODDv3: Notes on Salt values static DWORD seed ; DWORD randCanon (void) { seed = seed * 0x41C64E6D + 0x3039; return ( seed >> 16) & 0x7FFF; }
ODDv3: HMAC Key DWORD KeyID; // Encryption key ID DWORD BoardID; // Board ID DWORD KeySalt; // HMAC key salt Unknown function KeyID BoardID KBoardID (256 bit) KeySalt BodyID (from EXIF) SHA-1 based 256-bit hash HMAC key (256 bit)
ODDv3: Notes on HMAC key KBoardID value is depends on KeyID and BoardID values KeyID is in range 1..9 (inclusive) Every camera uses unique KBoardID Knowing KeyID, BoardID and KBoardID triplet allows forging ODD for any camera! Key can be extracted from the camera!
Verification devices: DVK-E1 Introduced with the EOS-1Ds in 2002 Works in Windows only Supports EOS-1Ds only Discontinued
Verification devices: DVK-E 2 Introduced in 2004 Works in Windows only Supports: 1Ds, 1Ds Mark II, 1D Mark II, 1D Mark II N, 20D, 30D, 5D Discontinued
Verification devices: OSK -E 3 Introduced in 2007 Works in 32-bit Windows only Supports: all ODD-enabled cameras Also support images encryption on 1D[s] Mark III+ Costs about $700
Model name ODD version V2 key Announced EOS-1D 2001-09-25 EOS-1Ds probably 1 1 2002-09-24 EOS 10D 2003-02-27 EOS 300D 2003-08-20 EOS- 1D Mark II 2 2 2004-01-29 EOS 20D 2 3 2004-08-19 EOS- 1Ds Mark II 2 4 2004-09-21 EOS 350D 2005-02-17 EOS 5D 2 5 2005-08-22 EOS- 1D Mark II N 2 6 2005-08-22 EOS 30D 2 7 2006-02-21 EOS 400D 2006-08-24
Model name KeyID seen vHash Announced EOS-1D Mark III 1 2007-02-22 EOS-1Ds Mark III 1 2007-08-20 EOS 40D 1 1 2007-08-20 EOS 450D 2 1 2008-01-24 EOS 1000D 2 1 2008-06-10 EOS 50D 1 2 2008-08-26 EOS 5D Mark II 1 2 2008-09-17 EOS 500D 3 2 2009-03-25 EOS 7D 4 2 2009-09-01 EOS-1D Mark IV 2 2009-10-20 EOS 550D 4 2 2010-02-08 EOS 60D 4 3 2010-08-26
Summary: What we can do? Dump camera’s memory Run our code on camera’s processor Extract secret keys from the camera Calculate and verify ODDv2 for models with known key Calculate ODDv3 for any camera using known KeyID/BoardID/KBoardID triplet
Summary: What we can’t do [ yet ]? Generate and verify ODDv2 images for models with unknown key Calculate KBoardID from KeyID/BoardID and verify ODDv3 if KBoardID is unknown for given KeyID/BoardID
Summary: What Canon can do? With currently available models – nothing With future models: Implement HMAC calculation in cryptoprocessor which does not expose secret key Prevent camera from running non-Canon’s code to avoid illegal usage of cryptoprocessor Hire people who really understands security :)
Conclusion We reported to CERT and Canon on September 21, 2010 Still no response from Canon… Verdict about image originality obtained via Canon’s OSK can’t be relied upon
Sorry, not the end  Canon issued notice for customers OSK-E3 FAQ ID: L00000101 , Last modified: 26-Jan-11 Issue : There is a possibility that retouched images <…> could be incorrectly verified as authentic <…> Answer: <…> customers who have previously purchased the DVK-E1, DVK-E2 and OSK-E3 are asked to please contact our  Help Desk  for more information on the next steps available to them.
Nikon’s solution Nikon Image Authentication Software introduced on Jun. 1, 2006 for Nikon D2Xs Offered on Nilkon’s web site for $649.95 Software version 1.1.1 supported models: D2Xs, D2X , D2Hs , D3 , D3X D200 , D300 , D300S , D700 Supported cameras price range: $1700 (D300S) - $8000 (D3X)
Nikon’s solution Verification software is protected from piracy (and reversing ; ) with dongle Digital signature is based on RSA-1024 Signing Key stored only within camera Signing Key is present in firmware updates (in obfuscated form), and could be extracted without having camera!
Epson’s way Epson Introduced Revolutionary Image Authentication System (IAS) for Epson Digital Cameras on 5 April 1999 IAS Version 2.0 supported cameras: EPSON PhotoPC 700, 750Z, 800, 850Z Software-only verification solution Seems to be discontinued in year 2000
Another approaches JPEGsnoop : analyze JPEG compression and determine which software/firmware most likely was used to encode the image Image Authentication by Detecting Traces of Demosaicing An Authenticated Camera : paper from 1996 by B. Schneier, J. Kelsey, D. Wagner, and C. Hall
Thank you! ;) Dmitry Sklyarov Уязвимости систем контроля подлинности цифровых фотографических изображений

More Related Content

Positive Hack Days. Sklyarov. Vulnerabilities in the Systems of Authenticity Control of Digital Photographic Images

  • 1. Vulnerabilities in the Systems of Authenticity Control of Digital Photographic Images Positive Hack Days Dmitry Sklyarov
  • 2. What is Original Decision Data It is too easy to edit photos… ODD is added to the image file by camera and expected to provide information to detect any image alteration Modified!
  • 3. My first DSLR – Canon EOS 350D Great piece of hardware Like it very much! (honestly! :) Does not support Original Image Verification features :(
  • 4. My next DSLR – Canon EOS 30D Even better than 350D : ) Custom Function 19: Add Original Decision Data to each picture taken
  • 5. EOS 30D: ODD in .JPG file ODD is stored as 160 (0xA0) bytes appended after JPEG EOI ( 0xFFD9 ) marker File offset of ODD is stored as 32-bit value in Tag 0x0083 inside EXIF/MakerNote IFD (Image File Directory) .JPG file JPEG SOI (0xFFF8) marker EXIF data JPEG EOI (0xFFF9) marker ODD: 160 (0xA0) bytes JPEG main image EXIF MakerNote IFD (Canon-specific) Tag 0x0083: ODD offset: 32 bits
  • 6. EOS 30D: ODD dump 0000 : FF FF FF FF 02 00 00 00 59 89 7D ED 86 BE 89 C8 0010 : 68 98 52 0F 4C C2 E0 86 1A BF BA DC 04 00 00 00 0020 : 00 00 00 00 C6 45 00 00 43 1B 0B 00 D6 15 F0 36 0030 : 91 92 21 DC 9B 33 B8 20 C9 C7 F2 EC 04 7C 9E 5B 0040 : 01 00 00 00 00 00 00 00 36 00 00 00 62 99 34 61 0050 : A9 17 AA DB 14 BE 60 0C 20 73 F1 B8 21 DD 6B 90 0060 : 02 00 00 00 3A 00 00 00 02 03 00 00 FC 45 9E 9A 0070 : 8B 1E 7D 26 F0 7C 5D A3 B1 A9 42 17 75 0F 41 0B 0080 : 03 00 00 00 40 03 00 00 86 42 00 00 9B E2 81 AE 0090 : 59 D8 21 6D 0F 9B 15 D0 CA 85 28 D8 44 7F 8F 5D ODD marker ODD version Number of Regions Region IDs Region offsets Region lengths
  • 7. ODDv2: Regions layout R0: Main Image R1: From 0 to Tag 0x0112 of EXIF Main IFD (Orientation tag) R2: From Orientation tag to ODD Offset tag R3: From ODD Offset tag to Main Image Region 1 EXIF Orientation tag (4 bytes) Region 2 EXIF ODD Offset tag (4 bytes) Region 3 Region 0 (Main Image) ODD (160 bytes)
  • 8. ODDv2: General structure typedef struct { DWORD marker ; // Marker == ~ 0 DWORD ver; // ODD version == 2 BYTE unknown _1[ 20 ]; DWORD nRegions; // Number of Regions == 4 struct { DWORD id; // Region ID DWORD o; // Region data offset DWORD cb; // Region data length BYTE unknown _2[ 20 ]; } r[4]; // Regions } T_ODD_v2; // sizeof(T_ODD_v2) == 0xA0
  • 9. ODDv2: Guessing unknown s Field before regions definition Represents signature for the whole image file? Field inside region definition Hold signature of the particular region data? Signature length is always 20 bytes Too short for asymmetric , but matches SHA-1 length Symmetric SHA-1 based authentication? May be HMAC-SHA-1?
  • 10. Explore CHDK (Canon Hacker's Development Kit) Wiki and forum Dump firmware using “blinking” or some other technique Use IDA Pro to analyze dumped ARM code Looking into camera’s firmware Three easy steps :)
  • 11. ODDv2: Clarified structure typedef struct { DWORD marker ; // Marker == ~ 0 DWORD ver; // ODD version == 2 BYTE imgHMAC[SHA_DIGEST_LENGTH ]; DWORD nRegions; // Number of Regions == 4 struct { DWORD id; // Region ID DWORD o; // Region data offset DWORD cb; // Region data length BYTE HMAC [ SHA_DIGEST_LENGTH ]; } r[4]; // Regions } T_ODD_v2; // sizeof(T_ODD_v2) == 0xA0
  • 12. ODDv2: Region HMAC Hash region data bytes with MD5 Repeat 128-bit region hash value 4 times to fill 64-byte buffer Calculate HMAC for the buffer, store result in ODDv2.r[i].HMAC MD5 Region[i] data bytes Rgn[i] hash HMAC-SHA-1 Rgn[i] HMAC HMAC key Rgn[i] hash Rgn[i] hash Rgn[i] hash Rgn[i] hash
  • 13. ODDv2: Image file HMAC Merge four 1 28-bit hash values for all 4 regions to fill 64-byte buffer Calculate HMAC for the buffer, store result in ODDv2.imgHMAC HMAC-SHA-1 File HMAC HMAC key Rgn[0] hash Rgn[1] hash Rgn[2] hash Rgn[3] hash
  • 14. ODDv2: What is HMAC key Length is 256 bits (32 bytes) Builds from two 128-bit parts, each part is stored separately in obfuscated form Last 32 bits are replaced by camera’s BodyID (stored in EXIF) before HMAC calculation de-obfuscated Left part (128 bits) de-obfuscated Right part (128 bits) BodyID (32 bits)
  • 15. ODDv2: Notes on HMAC key Key value is the same for all cameras of some particular model (e.g. EOS 30D) Different camera models (5D, 20D, 30D) uses different keys Knowing key for particular model allows forging ODD for any camera of that model! Key can be extracted from the camera!
  • 16. EOS 40D: New version of ODD ODD is stored within EXIF ODD version is 3 Image file length is stored inside ODD File is treated as set of areas (based on content type) Area could contain several regions Integrity of each area monitored independently
  • 17. ODDv3: Area layout in .JPG file Main image All other data Orientation User comment Check marks Thumbnail Area 2 (other) ODD (excluded from Area 2) Area 1 (Main image) Area 3 (Orientation) Area 4 (User comment) Area 6 (Thumbnail) Area 5 (Check marks) Note: ODD is not included in any area Exif data
  • 18. ODDv3: General structure ODDv3 Header Information Image information Area descriptors Padded with zeros Marker and Version Image file signature ODD Info signature
  • 19. ODDv3: Header structure typedef struct { DWORD marker ; // Marker == ~ 0 DWORD ver; // ODD version == 3 DWORD cbImg Sig; // len(Sign( Image) ) BYTE i mg Sig [cbImg Sig ]; // Sign (Image ) DWORD cbInfo Sig ; // len(Sign (oddInfo )) BYTE i nfo Sig [cbInfo Sig ]; // Sign (oddInfo) } T_ODDv3_Hdr; Note: cbImg Sig and cbInfo Sig are always == 20 == SHA_DIGEST_LENGTH
  • 20. ODDv3: Area structure typedef struct { DWORD id; // Area ID DWORD cbSalt ; // Salt length BYTE abSalt[cbSalt];// Salt DWORD cb Sig ; // Len(Sign(Area)) BYTE ab Sig [cb Sig ]; // Sign(Area) DWORD nRange; // Ranges count struct { DWORD o; // Range offset DWORD cb; // Range length } r[nRange]; // Array of r anges } T_ODDv3_Area;
  • 21. ODDv3: Info part structure typedef struct { DWORD cbInfo; // Length of Info part DWORD cbSigSalt; // Image/oddInfo salt length BYTE s igSalt[cbSigSalt]; // Image/oddInfo salt DWORD v3; // Version again? == 3 DWORD cbFile; // Total size of file DWORD vHash; // 1 : VxWorks, 2 or 3: DryOS DWORD KeyID; // Encryption key ID DWORD BoardID; // Board ID DWORD KeySalt; // HMAC key salt DWORD nArea; // Number of areas follows T_ODDv3_Area[ nArea ]; // Area descriptions BYTE zeros[]; // Zero filling } T_ODDv3_Info;
  • 22. Ver 2 and 3, OS: DryOS Note: Salt is not used (but still stored in ODD) ODDv3: Hash algorithm version Ver 1, OS: VxWorks SHA-256 Data bytes Result MD5 Data bytes Hash Result PRNG Salt Random1 Random2 MD5 Hash+ Random1 MD5 Hash+ Random 2
  • 23. Salt values are obtained from weak PRNG Seed value is based on total number of shots taken by camera ( Shutter Counter ) ODD information could be used to discover actual Shutter Counter value! ODDv3: Notes on Salt values static DWORD seed ; DWORD randCanon (void) { seed = seed * 0x41C64E6D + 0x3039; return ( seed >> 16) & 0x7FFF; }
  • 24. ODDv3: HMAC Key DWORD KeyID; // Encryption key ID DWORD BoardID; // Board ID DWORD KeySalt; // HMAC key salt Unknown function KeyID BoardID KBoardID (256 bit) KeySalt BodyID (from EXIF) SHA-1 based 256-bit hash HMAC key (256 bit)
  • 25. ODDv3: Notes on HMAC key KBoardID value is depends on KeyID and BoardID values KeyID is in range 1..9 (inclusive) Every camera uses unique KBoardID Knowing KeyID, BoardID and KBoardID triplet allows forging ODD for any camera! Key can be extracted from the camera!
  • 26. Verification devices: DVK-E1 Introduced with the EOS-1Ds in 2002 Works in Windows only Supports EOS-1Ds only Discontinued
  • 27. Verification devices: DVK-E 2 Introduced in 2004 Works in Windows only Supports: 1Ds, 1Ds Mark II, 1D Mark II, 1D Mark II N, 20D, 30D, 5D Discontinued
  • 28. Verification devices: OSK -E 3 Introduced in 2007 Works in 32-bit Windows only Supports: all ODD-enabled cameras Also support images encryption on 1D[s] Mark III+ Costs about $700
  • 29. Model name ODD version V2 key Announced EOS-1D 2001-09-25 EOS-1Ds probably 1 1 2002-09-24 EOS 10D 2003-02-27 EOS 300D 2003-08-20 EOS- 1D Mark II 2 2 2004-01-29 EOS 20D 2 3 2004-08-19 EOS- 1Ds Mark II 2 4 2004-09-21 EOS 350D 2005-02-17 EOS 5D 2 5 2005-08-22 EOS- 1D Mark II N 2 6 2005-08-22 EOS 30D 2 7 2006-02-21 EOS 400D 2006-08-24
  • 30. Model name KeyID seen vHash Announced EOS-1D Mark III 1 2007-02-22 EOS-1Ds Mark III 1 2007-08-20 EOS 40D 1 1 2007-08-20 EOS 450D 2 1 2008-01-24 EOS 1000D 2 1 2008-06-10 EOS 50D 1 2 2008-08-26 EOS 5D Mark II 1 2 2008-09-17 EOS 500D 3 2 2009-03-25 EOS 7D 4 2 2009-09-01 EOS-1D Mark IV 2 2009-10-20 EOS 550D 4 2 2010-02-08 EOS 60D 4 3 2010-08-26
  • 31. Summary: What we can do? Dump camera’s memory Run our code on camera’s processor Extract secret keys from the camera Calculate and verify ODDv2 for models with known key Calculate ODDv3 for any camera using known KeyID/BoardID/KBoardID triplet
  • 32. Summary: What we can’t do [ yet ]? Generate and verify ODDv2 images for models with unknown key Calculate KBoardID from KeyID/BoardID and verify ODDv3 if KBoardID is unknown for given KeyID/BoardID
  • 33. Summary: What Canon can do? With currently available models – nothing With future models: Implement HMAC calculation in cryptoprocessor which does not expose secret key Prevent camera from running non-Canon’s code to avoid illegal usage of cryptoprocessor Hire people who really understands security :)
  • 34. Conclusion We reported to CERT and Canon on September 21, 2010 Still no response from Canon… Verdict about image originality obtained via Canon’s OSK can’t be relied upon
  • 35. Sorry, not the end  Canon issued notice for customers OSK-E3 FAQ ID: L00000101 , Last modified: 26-Jan-11 Issue : There is a possibility that retouched images <…> could be incorrectly verified as authentic <…> Answer: <…> customers who have previously purchased the DVK-E1, DVK-E2 and OSK-E3 are asked to please contact our  Help Desk  for more information on the next steps available to them.
  • 36. Nikon’s solution Nikon Image Authentication Software introduced on Jun. 1, 2006 for Nikon D2Xs Offered on Nilkon’s web site for $649.95 Software version 1.1.1 supported models: D2Xs, D2X , D2Hs , D3 , D3X D200 , D300 , D300S , D700 Supported cameras price range: $1700 (D300S) - $8000 (D3X)
  • 37. Nikon’s solution Verification software is protected from piracy (and reversing ; ) with dongle Digital signature is based on RSA-1024 Signing Key stored only within camera Signing Key is present in firmware updates (in obfuscated form), and could be extracted without having camera!
  • 38. Epson’s way Epson Introduced Revolutionary Image Authentication System (IAS) for Epson Digital Cameras on 5 April 1999 IAS Version 2.0 supported cameras: EPSON PhotoPC 700, 750Z, 800, 850Z Software-only verification solution Seems to be discontinued in year 2000
  • 39. Another approaches JPEGsnoop : analyze JPEG compression and determine which software/firmware most likely was used to encode the image Image Authentication by Detecting Traces of Demosaicing An Authenticated Camera : paper from 1996 by B. Schneier, J. Kelsey, D. Wagner, and C. Hall
  • 40. Thank you! ;) Dmitry Sklyarov Уязвимости систем контроля подлинности цифровых фотографических изображений

Editor's Notes

  1. Good morning, ladies and gentlemen! My name is Dmitry Sklyarov. I’m employed as Information Security analyst at ElcomSoft, security company based in Moscow, Russia. I’d like to present a speech on a subject “Forging Canon Original Decision Data”.
  2. Nowadays editing digital images is a common task, and sometime it is very difficult to make sure that image was not altered. In 2002 Canon introduced O riginal I mage E valuation S ystem – combination of EOS 1Ds camera and Data Verification Kit able to detect any image alteration.
  3. In December 2005 I’ve got my first Digital Single-Lens Reflex camera – Canon EOS 350D. Since that I like Canon’s cameras very much. Nearly at the same time I read about Canon’s Origin Image Verification system for the fist time and discovered that my camera does not support such features :(
  4. After couple of years I’ve upgraded to EOS 30D, and finally got the chance to check how secure Original Verification System is. Most of Canon’s DSLR has Custom Function which enables ODD in the menu.
  5. I just made several images in close conditions without ODD and with adding ODD, and compared them. There were only two differences: additional 160 bytes at the end of file and offset of the added data within one of the EXIF tags.
  6. Analyzing of the ODD data shows that some fields are always the same (highlighted in green), some other are easy-to-understand (blue and yellow), but all other data looks like random binary values. Variable fields that were easy to understand are holds offsets and length of some regions within the image file.
  7. That regions are covers whole file except values for image rotation, ODD offset and ODD itself.
  8. C-like notation of ODD structure is displayed, and it still has unknowns in areas, always 20 bytes in length.
  9. Trying to guess what that unknown areas could mean leads to the idea that signature for each region and the whole file is stored in ODD, SHA-1 is involved in calculations and most probably Hash-based Message Authentication Code is used.
  10. The only way to verify guesses was looking into camera’s firmware. In general, analyzing firmware is not as simple as reverse-engineering, for example, Windows application. No file to analyze. No public documentation. No way to run debugger… Fortunately, Canon’s cameras are popular and got attention of smart peoples many years ago. There is great project named CHDK exist, and using information provided by people involved in it you could make a fast start. Another great tool that makes code analysis much easier is, of cause, IDA Pro.
  11. Making deep research of dumped firmware confirmed all guesses. Early unknown areas contain HMAC-SHA-1 values.
  12. Data for each region is hashed with MD5. Resulting value repeated 4 times and processed with HMAC to calculate value stored in ODD for each region.
  13. Value for the whole file is calculated in similar way, but MD5 values for all 4 regions are processed with HMAC.
  14. But calculating HMAC requires not only data but also a secret key. In Canon EOS 30D that key is created dynamically from obfuscated values stored in camera’s memory. Last 32 bits of HMAC key are equal to camera’s BodyID – kind of unique 32-bits camera’s ID.
  15. Additional analysis shows that all camera of the same models uses identical HMAC key (with exception of BodyID bits), but each model uses its own key. The main problem for the Origin Image Verification security it that HMAC key at some moment is resides in camera’s RAM in de-obfuscated form and could be extracted. At least I was able to do so for several camera models ;) Another way to get the key – find obfuscated values in Flash ROM and de-obfuscate them manually. And, finally, knowing the key for the particular model means possibility to calculate proper ODD values for arbitrary image data using the same way as camera does.
  16. After finishing with EOS 30D I’ve asked one of my friends who owns EOS 40D to make several shots with ODD turned on and detected that Canon has changed ODD format. ODD is now more flexible, implements version 3, stored within EXIF, occupies more space and holds more values.
  17. Now image file is treated as a set of areas, depending on type of the data inside it. Main image and thumbnail image data, orientation data, user comment and some check marks areas are processed independently as contiguous regions. Area #2 covers all other bytes of the image file except ODD data and padding bytes between Thumbnail and Main image that added to align main image on 32-bit boundary. Area #2 constructed as a set of contiguous regions.
  18. ODDv3 for JPG files occupies 512 (0x200) bytes, some of them are unused, Generally, ODDv3 consists of header and information parts. Header holds ODD marker, version and calculated signature values for the whole image and ODD Information part. Information part itself contains some data related to image in whole and area descriptors. Unused space in Information part is filled with zeros.
  19. Here is C-like description of the ODDv3 header. As you can see it can hold signatures of variable length, but in all real files signature length is always 20 bytes.
  20. Each area has sequential 1-based ID, plus Salt and Signature values associated with it. Length of Salt is always 4 bytes, and length of Signature is always 20 bytes. Area description defines list of contiguous ranges that completely covers area’s data. Number of ranges within area affects structure size, so it is not a constant.
  21. And, finally, here is general structure of ODDv3 information part. HMAC for the whole information part is calculated (to check its integrity) and stored in ODD header. Again, Salt value of variable length is present, and its length is always 4 in real-life images. File length is stored in ODD too. Interesting member is vHash – version of hash algorithm used to process ranges data before passing resulting hash value to HMAC. As you remember, in ODDv2 it was MD5.
  22. In early models with ODDv3 hash is MD5 too, but after calculating 16-byte value some Pseudo-Random generator seeded by Salt was used to extend 16 bytes into 32. Such version of hashing algorithm has number 1. In August 2008 Canon releases new camera EOS 50D based on new operating system – DryOS. And since that data is hashed with SHA-256 and Salt is not used at all. Such hashing versions has number 2 and 3 (both uses the same algorithm).
  23. Salt values in ODDv3 are obtained from weak (invertible) PRNG. PRNG is seeded with Shutter Counter value. So, actual Shutter Counter value (which neither written to EXIF nor available through camera’s menu system) could be recovered from ODD.
  24. There are three more members of the Information structure that are requires to pay attention too. They are KeyID, BoardID and KeySalt. Actually, KeyID and BoardID are never involved in any calculation inside the camera. But there is some unknown (for me) function exists that converts that pair of 32-bit values into 256-bit key KBoardID. That value is stored in camera’s memory in obfuscated form and, again, could be extracted from there. De-obfuscated value of KBoardID is merged with KeySalt and BodyID, processed with 256-bit hash function which based on SHA-1 and HMAC key is produced as a result. So, in ODDv3 HMAC key is different for every camera (due to KeyID, Board ID and BodyID which are never the same all together). And even shots from one camera are signed by different HMAC keys due to KeySalt.
  25. Value of KeyID is always within the range from 1 to 9. Originality Verification tool does not checks any relation between camera model, KBoardID, KeyID and BoardID. So, knowing one triplet of values is enough to sign images for any ODDv3 camera.
  26. Now several words about verification devices. First version of verifier supports only one camera model – EOS-1Ds
  27. Next version of verification device supports all ODDv2 enabled models
  28. The most recent device supports all cameras and also could be used to encrypt and decrypt images in top Canon’s cameras. After ElcomSoft spent moneys for this tiny piece of hardware I finally got the chance to verify if my finding correct or not. And I was not surprised when all images signed by me successfully passed originality verification.
  29. Here is summary of Canon’s DSLR cameras developed before year 2007. There are three models marked by green. I’ve got a chance to get such cameras in my hands and extracted keys from them. Models marked by red still uses keys which are unknown for me. All other cameras does not supports ODD. V2 Key number is internal model number that used during verification of image originality.
  30. These cameras appears on the market in year 2007 or later. All of them supports ODDv3. For models marked in green BoardID, KeyID and KBoardID were extracted from dump. For models marked in yellow KeyID was obtained from ODD-enables images. For 1D cameras no images with ODD available but hashing algorithm version could be derived from firmware update. KeyID is not stored in firmware. So, it is possible that cameras of the same model would have different KeyID.