Re: [Cryptech Tech] CLI and UARTs

[Basil Dolmatov]

Ook, will use magnifying glass.
Thanks. 

dol@ с iPad

> 11 авг. 2016 г., в 20:27, Rob Austein <s...@hactrn.net> написал(а):
> 
> At Thu, 11 Aug 2016 20:20:48 +0300, Basil Dolmatov wrote:
>> 
>> Could anyone advise proper jumper settings for fallback to FTDI?
> 
> The daughterboards have switches instead of jumpers, and the FTDI
> positions are labeled, although it helps to have little teeny eyes to
> read the little teeny labels next to the little teeny switches.
> ___
> Tech mailing list
> Tech@cryptech.is
> https://lists.cryptech.is/listinfo/tech

___
Tech mailing list
Tech@cryptech.is
https://lists.cryptech.is/listinfo/tech

Re: [Cryptech Tech] Tamper detection

[Basil Dolmatov]

dol@ с iPad

> 19 июля 2016 г., в 10:54, Fredrik Thulin  написал(а):
> 
> 
> The next revision (rev04) ought to fix the current leakage from the VBAT to 
> the 3V3 rail, but after some more thinking I think maybe the tamper 
> daughterboard can have the battery connector/super-cap. That way the 
> daughterboard will be usable with the current rev03's too.
> 
> Stated differently, the tamper daughterboard could feed the VBAT on the Alpha 
> instead of being fed by the VBAT on the Alpha.
> 
> Any downsides to that?
Daughter board can be absent, this should not lead to unusable tamper processor.

> 
> /Fredrik
> 
> 
> 
> ___
> Tech mailing list
> Tech@cryptech.is
> https://lists.cryptech.is/listinfo/tech

___
Tech mailing list
Tech@cryptech.is
https://lists.cryptech.is/listinfo/tech

Re: [Cryptech Tech] Alpha SDRAMs

[Basil Dolmatov]

Incredible!!!

Thanks, Pavel! 

dol@ с iPad

> 22 мая 2016 г., в 14:37, Pavel Shatov  написал(а):
> 
> Hello!
> 
> I got one of the Alpha boards from Fredrik and was busy trying to bring up 
> the two on-board SDRAM chips. I believe, I finally have them working.
> 
> There turns out to be a stupid bug in low-level HAL code. Actually, there are 
> in fact two similar bugs, that don't cancel each other out unfortunately.
> 
> In brief, our STM32 should have two independent SDRAM banks. When you start 
> reading the fine print, you find out that they are not completely 
> independent, i.e. they can only operate at the same frequency and share some 
> of the timing parameters. This is not a problem itself, because we have two 
> identical memory chips. The problem is that there are two configuration 
> registers, the first register also controls some of the parameters for the 
> second bank, therefore in the second register corresponding control bits are 
> reserved. Sane person would configure the first bank, read its configuration 
> register, mask reserved bits and write into the second bank. I believe this 
> is what original FMC_SDRAM_Init() and FMC_SDRAM_Timing_Init() thought they 
> were doing when they tried to configure the second bank, but those functions 
> just messed up configuration of both banks instead.
> 
> Anyways, both external memory chips seem to work now. I uploaded simple test 
> program, that basically fills entire memory with pseudo-random pattern, reads 
> it back and compares with what was written.
> 
> 
> -- 
> With best regards,
> Pavel Shatov
> ___
> Tech mailing list
> Tech@cryptech.is
> https://lists.cryptech.is/listinfo/tech

___
Tech mailing list
Tech@cryptech.is
https://lists.cryptech.is/listinfo/tech

Re: [Cryptech Tech] Alpha status

[Basil Dolmatov]

Nice!
Waiting from other news from battlefield! 

dol@ с iPad

> 12 мая 2016 г., в 10:44, Fredrik Thulin  написал(а):
> 
>> On torsdag 12 maj 2016 kl. 11:19:16 CEST Fredrik Thulin wrote:
>> We've started the bring up of the Alpha board. It is alive!
>> 
>> Power levels and sequencing have been tested OK, and we see the FPGA on
>> JTAG.
>> 
>> I'll try to live-tweet the rest of it @fredrikt5.
> 
> The first day of testing was a great success. All the hardware we tested 
> today 
> basically worked.
> 
> What remains to test tomorrow is the FMC bus. This is the most complicated 
> part of the board, with 32 data bits and 24 (?) address bits moving at about 
> 100 MHz.
> 
> Given the encouraging results from today I can't be anything but optimistic 
> =).
> 
> /Fredrik
> 
> ___
> Tech mailing list
> Tech@cryptech.is
> https://lists.cryptech.is/listinfo/tech
___
Tech mailing list
Tech@cryptech.is
https://lists.cryptech.is/listinfo/tech

Re: [Cryptech Tech] road to berlin

[Basil Dolmatov]

dol@ с iPad

> 2 мая 2016 г., в 16:26, Pavel Shatov  написал(а):
> 
> 02.05.2016 10:43, Fredrik Thulin пишет:
>> On Monday, May 02, 2016 12:37:50 AM Paul Selkirk wrote: ...
>>> The AVR has to do approximately the following: - receive a tamper
>>> interrupt from an external circuit (currently a panic button) -
>>> wipe the MKM - raise an interrupt on the ARM, so it can do whatever
>>> it needs to do - light an LED (red, of course)
>>> 
>>> If we get that right, we might never have to upgrade the AVR.
>> 
>> I agree. I would consider it nice to have (or harmful =) ) to have a
>> software upgrade path for the AVR before Berlin. We could absolutely
>> make a way to transfer firmware to the AVR from the FPGA using
>> GPIOs, but with close to zero benefit at this stage.
> 
> I think, some people will even object to DFU option being present for the 
> tamper detection block. What if malicious user crafts dummy tamper detection 
> firmware, that only lights the red panic LED, but skips actual wiping of the 
> secret key?
> 
Agree... It is really dangerous to implement this I pen hurry and without real 
understanding attack vectors. 
>> My reasoning:
>> 
>> The whole tamper circuitry is currently a development module. It is
>> nice to have a way to erase any keys in the device when re-purposing
>> it or similar, but it currently requires pressing a button on the
>> bottom side of the PCB. If someone wants to actually add tamper
>> protection to the Alpha using the AVR GPIOs, it is not unreasonable
>> to expect them to program the AVR using an ISP programmer connected
>> to the programming header.
> 
> I agree that if someone wants to customize the tamper detection block, he 
> will most probably know how to deal with the hardware part (add new sensors 
> to board, support them in the tamper detection firmware, etc), so he will 
> definitely have AVR programming cable and won't need the DFU option.
> 
>> 
>> So the main reason to make DFU for the AVR I can see would be to
>> streamline manufacturing, and I think we have other things to focus
>> on first.
>> 
>> /Fredrik
> 
> 
> -- 
> With best regards,
> Pavel Shatov
> ___
> Tech mailing list
> Tech@cryptech.is
> https://lists.cryptech.is/listinfo/tech
___
Tech mailing list
Tech@cryptech.is
https://lists.cryptech.is/listinfo/tech

Re: [Cryptech Tech] dev-bridge board

[Basil Dolmatov]

In that case let's look closer in reprogramming capabilities of two chips and 
compare 

dol@ с iPad

> 19 дек. 2015 г., в 0:12, Jacob  написал(а):
> 
>> On 12/18/2015 10:58 PM, Fredrik Thulin wrote:
>> 
>> 
>> I don't recall any specific discussions about the RTC, but I think we wanted 
>> it
>> battery powered (naturally, sort of). I have the feeling that might be 
>> possible with
>> the RTC in the STM32 too, in which case I believe there are no real reason 
>> to have
>> a separate one.
> 
> Yes it is possible. From the STM32F429 datasheet:
> 
> VBAT = 1.65 to 3.6 V: power supply for RTC, external clock 32 kHz oscillator 
> and backup registers (through power switch) when VDD is not present.
> 
> ___
> Tech mailing list
> Tech@cryptech.is
> https://lists.cryptech.is/listinfo/tech
___
Tech mailing list
Tech@cryptech.is
https://lists.cryptech.is/listinfo/tech

Re: [Cryptech Tech] About the TRNG

[Basil Dolmatov]

dol@ с iPad

> 19 дек. 2015 г., в 1:22, Jacob  написал(а):
> 
> 
> A question to the experts:
> 
> I fully understand the trust gained by having a custom made external analog 
> TRNG as we do here, but wouldn't be better to XOR the bitstream received from 
> our generator with the one embedded in the CPU(*)?
What means 'better' in this case?
Mixing two really good sources of entropy does not make output 'better' 
considering entropy quality.
This mixing can give one some hope that having mediocre entropy sources one can 
make the result better. 

Having a good source of entropy I can not see any reason for mixing it with 
other data.

> I mean, if the CPU 's TRNG is tainted, we will not be worse off, and if it is 
> not, the board will probably exhibit higher security in case our generator 
> would have some issues.
> 
> (*) from the STM32F429 datasheet: All devices embed an RNG that delivers 
> 32-bit random numbers generated by an integrated analog circuit
> (analog noise feeding into a shift register)
> 
> ___
> Tech mailing list
> Tech@cryptech.is
> https://lists.cryptech.is/listinfo/tech
___
Tech mailing list
Tech@cryptech.is
https://lists.cryptech.is/listinfo/tech

Re: [Cryptech Tech] About the TRNG

[Basil Dolmatov]

dol@ с iPad

> 19 дек. 2015 г., в 15:16, Dmitry Belyavsky <beld...@gmail.com> написал(а):
> 
> Dear Basil, 
> 
>> On Sat, Dec 19, 2015 at 1:11 PM, Basil Dolmatov <d...@reedcat.net> wrote:
>> 
>> 
>> dol@ с iPad
>> 
>> > 19 дек. 2015 г., в 1:22, Jacob <ja...@edamaker.com> написал(а):
>> >
>> >
>> > A question to the experts:
>> >
>> > I fully understand the trust gained by having a custom made external 
>> > analog TRNG as we do here, but wouldn't be better to XOR the bitstream 
>> > received from our generator with the one embedded in the CPU(*)?
>> What means 'better' in this case?
>> Mixing two really good sources of entropy does not make output 'better' 
>> considering entropy quality.
>> This mixing can give one some hope that having mediocre entropy sources one 
>> can make the result better.
>> 
>> Having a good source of entropy I can not see any reason for mixing it with 
>> other data.
> 
> If software can obtain random data from the system,  it may be useful to add 
> the true-random data to the standard system sources of it instead of using 
> the different hardware devices directly.
In this project hardware source is used for seeding software random generator 
only
> 
> -- 
> SY, Dmitry Belyavsky
___
Tech mailing list
Tech@cryptech.is
https://lists.cryptech.is/listinfo/tech