Positive Hack Days. Скляров. Уязвимости систем контроля подлинности цифровых фотографических изображений
•Als PPT, PDF herunterladen•
0 gefällt mir•1,314 views
В докладе рассматриваются практические аспекты надежности существующих систем обеспечения подлинности фотографических улик. Рассматривается уязвимость в системе проверки аутентичности фотографий Canon Original Data Security, предназначенной для подтверждения подлинности изображений, сделанных зеркальными цифровыми фотокамерами Canon.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Positive Hack Days. Скляров. Уязвимости систем контроля подлинности цифровых фотографических изображений
Ähnlich wie Positive Hack Days. Скляров. Уязвимости систем контроля подлинности цифровых фотографических изображений (20)
Mehr von Positive Hack Days
Mehr von Positive Hack Days (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Positive Hack Days. Скляров. Уязвимости систем контроля подлинности цифровых фотографических изображений
- 1. Уязвимости систем контроля подлинности цифровых фотографических изображений Positive Hack Days 19 мая 2011 Москва, Россия 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!
- 9. ODDv2: Guessing unknown s May be HMAC-SHA-1? Symmetric SHA-1 based authentication? Too short for asymmetric , but matches SHA-1 length Signature length is always 20 bytes Hold signature of the particular region data? Field inside region definition Represents signature for the whole image file? Field before regions definition
- 18. ODDv3: General structure ODDv3 Header Information Image information Area descriptors Padded with zeros Marker and Version Image file signature ODD Info signature
- 29. 2006-08-24 EOS 400D 2006-02-21 7 2 EOS 30D 2005-08-22 6 2 EOS- 1D Mark II N 2005-08-22 5 2 EOS 5D 2005-02-17 EOS 350D 2004-09-21 4 2 EOS- 1Ds Mark II 2004-08-19 3 2 EOS 20D 2004-01-29 2 2 EOS- 1D Mark II 2003-08-20 EOS 300D 2003-02-27 EOS 10D 2002-09-24 1 probably 1 EOS-1Ds 2001-09-25 EOS-1D Announced V2 key ODD version Model name
- 30. 2010-08-26 3 4 EOS 60D 2010-02-08 2 4 EOS 550D 2009-10-20 2 EOS-1D Mark IV 2009-09-01 2 4 EOS 7D 2009-03-25 2 3 EOS 500D 2008-09-17 2 1 EOS 5D Mark II 2008-08-26 2 1 EOS 50D 2008-06-10 1 2 EOS 1000D 2008-01-24 1 2 EOS 450D 2007-08-20 1 1 EOS 40D 2007-08-20 1 EOS-1Ds Mark III 2007-02-22 1 EOS-1D Mark III Announced vHash KeyID seen Model name
- 40. Thank you! ;) Dmitry Sklyarov Уязвимости систем контроля подлинности цифровых фотографических изображений
Hinweis der Redaktion
- 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”.
- 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.
- 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 :(
- 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.
- 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.
- 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.
- That regions are covers whole file except values for image rotation, ODD offset and ODD itself.
- C-like notation of ODD structure is displayed, and it still has unknowns in areas, always 20 bytes in length.
- 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.
- 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.
- Making deep research of dumped firmware confirmed all guesses. Early unknown areas contain HMAC-SHA-1 values.
- 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.
- Value for the whole file is calculated in similar way, but MD5 values for all 4 regions are processed with HMAC.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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).
- 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.
- 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.
- 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.
- Now several words about verification devices. First version of verifier supports only one camera model – EOS-1Ds
- Next version of verification device supports all ODDv2 enabled models
- 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.
- 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.
- 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.