[fprint] AES1660

[Andreas]

Hi Vasily,


in "what_we_know_so_far.txt", I explicitely marked all bulks that are 
changing among different runs. As I said: The bulks you considered:

 >> Look at log you've send to me,
 >> seq no 277, it's definitely non-encrypted data from sensor!
 >> 0x49, 0x44, 0x02 - envelope?
 >> 0x0d, 0x00, 0x00 - some multibyte command, no payload
 >> 0xe0, 0x22, 0x02 - E-data from sensor, 4 bit per pixel. Exact data
 >> starts from 0x22 byte, and looks like it's some 31-byte pattern:
 >>
 >> 2501 4892 a46d 93ec ff37 816c db7e 5b5a 1280 2449 da36 c9fe 7f13 
c8b6 edb7 a5
 >> Then after 0x222 bytes:
 >> 0xde, 0x10, 0x00 - histogram data
 >> After 0x10 bytes:
 >> 0xdf, 0x06, 0x00 - authentication message
 >>

...are not among them. So...

 > Played a bit with my AES1660, and looks like this frame is not
 > chaning... It does not matter
 > if finger is on sensor...

...yes. They are always the same.


I updated the zip:
- eliminated the mistake in sniff description (upload->download of "bulk 
583").
- added Petrs documentation (included zip file)

www.andreas-loos.com/aes1660.zip

One remark concerning Petrs tool: I could not really make it run on my 
machine. It contains also parts I do not agree with, for instance a 
"switch to raw" sequence which is in fact an exact copy of a part of 
what I sniffed in the win driver traffic. Hence there are two 
possibilities: The driver works in raw mode under windows (which is 
possible according to the last observations) or Petrs "switch to raw" 
does not what its name implies.

I did not have the time to produce new usb sniffs, for instance with 
covered scanner, but I will do in the next days.

Best,
andreas



On 15.11.2012 20:00, Vasily Khoruzhick wrote:
> On Wed, Nov 14, 2012 at 1:51 PM, Vasily Khoruzhick <anarsoul at gmail.com> wrote:
>> On Wed, Nov 14, 2012 at 1:05 PM, Andreas <krawatten at andreas-loos.com> wrote:
>>> Dear friends of AES1660,
>>>
>>>
>>> here you find my analysis of what is happening in the usb traffic between
>>> win driver and AES1660:
>>>
>>> http://www.andreas-loos.com/AES1660.zip
>>>
>>> The zip contains virtually anything I know so far. Vasily asked for usb logs
>>> with complete traffic that can be compared. For this, take for instance log
>>> 2 (my favorite reference), log 5 and log 8.
>>>
>>> The good news is that many commands seem to be not encrypted like in AES2550
>>> (or was it AES2850?). To be CORRECT in detail: There *are* in fact lots of
>>> encrypted commands, as Vasily remarks, but for them encryption is obviously
>>> the same in each run. So I think, these parts can be easily reproduced as
>>> black box.
>>>
>>> The bad news is that we still cannot switch the thing into raw mode or know
>>> anything about the encryption. (Thanks for your helpful comments, Vasily!
>>> You are probably right, keys are probably not transferred unencrypted and
>>> the 583 byte thing is surely not a single long key.)
>>>
>>> Any ideas how to proceed?
>>>
>>> Best,
>>> andreas
>>
>> Look at log you've send to me,
>> seq no 277, it's definitely non-encrypted data from sensor!
>> 0x49, 0x44, 0x02 - envelope?
>> 0x0d, 0x00, 0x00 - some multibyte command, no payload
>> 0xe0, 0x22, 0x02 - E-data from sensor, 4 bit per pixel. Exact data
>> starts from 0x22 byte, and looks like it's some 31-byte pattern:
>>
>> 2501 4892 a46d 93ec ff37 816c db7e 5b5a 1280 2449 da36 c9fe 7f13 c8b6 edb7 a5
>>
>> Then after 0x222 bytes:
>> 0xde, 0x10, 0x00 - histogram data
>> After 0x10 bytes:
>> 0xdf, 0x06, 0x00 - authentication message
>>
>> Regards
>> Vasily
>
> Played a bit with my AES1660, and looks like this frame is not
> chaning... It does not matter
> if finger is on sensor...
>
> Andreas, could you send me Petr's version of test app?
>
> Regards
> Vasily
>

-- 
___________________________________
  Andreas Loos
  Kurt-Exner-Straße 6
  10249 Berlin

  http://www.andreas-loos.com
___________________________________