Elektroda.pl
Elektroda.pl
X
Elektroda.pl
AdexAdex
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

TRNG z użyciem 4ech ADC Atmel AVR-czujnika Halla i temperatury

07 Sty 2014 20:15 4716 11
  • Poziom 16  
    Witam, przeszukuję forum pod kątem jak najprostrzych sprzętowych generatorów losowych bitów, ponieważ w jednym projekcie na AVR ATTiny85 chciałbym zastąpić programowy generator sprzętowym ze względu na ograniczone możliwości obliczeniowe.
    Nie jest to projekt kryptograficzny, ale być może z ciekawości chciałbym jakość generowanych bitów sprawdzić.
    W tym projekcie wykorzystuję 3y ADC do pomiaru prądu napięcia i ustawień potencjometru,
    przy czym pomiar prądu jest na czujniku pola magnetycznego SS495A.

    Zastanawiam się czy po prostu po odczytaniu 10bitowych wartości z ADC nie wziąć najmniej znaczącego bitu i jego użyć jako źródła 0/1 ?
    Sam SS495A jest ciekawy bo prawdopodobnie jest zakłocany nieznacznie przez pole magnetyczne z otoczenia i tym samym być może byłby dobrym źródłem TRNG?

    Idea jest taka że biorę 3y odczyty z ADCi robię XOR + maska na najmniej znaczący bit:
    TRNG= (ADC1^ADC2^ADC3^ADC4)& 0x01;

    Ma też ten AVR wbudowany czujnik temperatury, więc dodatkowo 4y odczyt z tego ADC4 mogę dodać.
    Myślałem też winnym projekcie dedykowanym do takiego generatora użyć rezystora LDR oświetlanego jakąś diodą albo kilkoma i mierzyć natężenie światła i oczywiście też ostatni najmniej znaczący bit jako TRNG użyć.
    Tutaj jest bardzo zaawansowana metoda:
    https://www.elektroda.pl/rtvforum/viewtopic.php?p=5628959#5628959
    w tym PDF:
    http://arxiv.org/PS_cache/quant-ph/pdf/9912/9912118v1.pdf

    Ale być może taki TRNG z tych 4ech ADC AVRa też by był nienajgorszy?
    Ktoś kojarzy oprogramowanie do testowania RNG?
    Np. mam ciąg 01001010101000100101 w pliku tekstowym, czy binarnym bajty z losowymi bitami w ilości 20000 czyli ok. 2.5kB i jakimś programem (najlepiej Open Source) pod Linux analizuję jakość tak wygenerowanych ciągów?
    Update: W tym PDF wyżej jest estymacja PI metodą Monte-Carlo opisana jako sposobu oszacowania jakości generowanych liczb losowych i na potrzeby tego projektu powinno to wystarczyć-wystarczy napisać kilka lini kodu w C lub Java i analizować bity w ten sposób:
    TRNG z użyciem 4ech ADC Atmel AVR-czujnika Halla i temperatury
    Nie jest jakimś problemem dla mnie przesłanie tych bitów z AVR na PC.... nawet bezprzewodowo z optoizolacją (za pomocą światła z jednej diody LED), więc pozostaje sprawdzić jakiej jakości te losowe bity będą z takiego TRNG na AVR ATiny85 :idea:
  • AdexAdex
  • Poziom 43  
    aneuro napisał:

    Yyy? Że co? :D

    w tym PDF:
    aneuro napisał:

    No tutaj już może tak.

    Ale ja myślę że metoda z 3 odczytami ADC i XORowaniem ich najmłodszych bitów będzie już bardzo dobra.
  • AdexAdex
  • Poziom 16  
    atom1477 napisał:
    aneuro napisał:

    Yyy? Że co? :D

    Przecież to ten sam post...
    "Najlepszy jak dotąd projekt pod każdym względem (także ceny) znajduje się tutaj: http://arxiv.org/PS_cache/quant-ph/pdf/9912/9912118v1.pdf"

    Problem z 4xADC taki że muszę podkręcić częstotliwość próbkowania, żeby więcej tych losowych bitów zebrać, bo obecnie miałem na 125kHz ADC ustawione... ale i tak robię średnią ruchomą z tych odczytów, więc przy okazji podkręci się taktowanie i powinno działać...
  • Poziom 16  
    przy 250kHz chyba nie powinno być tragicznie chyba nawet z samą dokladnością pomiarów bo oprócz tego w jednym projekcie będą dane z czujników zbierane.
    Mam wtedy mozliwość wykonania ok. 20000 odczytów ADC/sekundę bo w ATTiny85 coś koło 12 cykli trwa to.
    Jeśłi jeden losowy bit będzie generowany z 4ech ADC (wewnętrzny czujnik temperatury nie będę przełączał na ten referencyjny wymagany do odczytów w skali temperatury, żeby nie tracić na tym przełączeniu jednego pomiaru ADC) czyli coś w okolicy 5000 losowych bitów na sekundę mi wychodzi szacunkowo.
    Zakładając że w jednym z projektów wystarczy mi liczba 4bitowa losowa, bo chcę prawdopodobieństwa ze skokiem ok. 0.1 mieć, to mi daje ok. 1250 czyli jedną taką 4bitową liczbę co 1 milisekundę i to by mnie urządzało.
    Zobaczymy jakiej jakości będą te bity przy takich ustawieniach, bo do testów będę losował dłuższe i wspomnianą metodą wyżej aproksymacji PI sprawdzę jak to wyjdzie ;)
  • Poziom 16  
    Akurat zegar systemowy w wiekszości projektów mam zrobiony na przerwaniu jednego z timerów ustawionym na ok. 1ms, a ADC dobieram do konkretnego projektu w zależności od potrzeb.
    W tym czasie wiele odczytów ADC da się zrobić i na tej żółtej diodzie jak w jednym z projektów poniżej będę przesyłał do kompa generowane testowo bity.
    Docelowo to będzie pin pod SCL I2C, ale sygnalizację być może sobie tak czy inaczej zostawię.
    TRNG z użyciem 4ech ADC Atmel AVR-czujnika Halla i temperatury
    Ciekawy jestem jaka by była jakość generowanych losowych bitów, gdyby jak powyżej próbkować niepodłączone do niczego piny ADC-bo chyba tak co niektórzy kombinowali czasami-tyle że z tym Xor'ami i zegar ADC ok 250kHz ;)
    Mam okazję to potestować zanim dolutuję potencjometry i zastanawiam się czy wlutować może jakieś kawałki drucików jako anteny, żeby na tych ADC coś ciekawszego bardziej chaotycznego odczytać, czy wystarczy tak jak jest?
    Tylko 1en z 3ech ADC jest 2ma rezystorami ściągnięty do masy, więc na nim nic ciekawego nie odczytam, ale pozostają 2a jeszcze i ma ten AVR wbudowany czujnik temperatury na 4ym ADC.
    Tam gdzie ejst RESET jest 3ci ADC, ale nie bawię się w HV programowanie.
    2a ADC ATTiny85 nie są podłączone do niczego tylko do ścieżek przylutowane i nie jest to jeszcze niczym zabezpieczone poza cienką warstwą kalafoni przed lutowaniem.

    Pozostało kawałek programu napisać i wsadzić tam ATTiny85 do testów, bo napięcia są poprawne i ręcznie wszystko ładnie się załącza, a kiedyś można coś podobnego jako TRNG na I2C sobie zrobić, bo mam wolne po prawej stronie 2a dolne piny bez ADC, więc softwarowe I2C będzie ładnie śmigać :D

    Akurat ta płytka jako sterownik zgrzewarki ma robić po wstawieniu triaka, no ale temat TRNG też ciekawy i jak się uda zostanie wykorzystany w tym steroniku również...
    Po stronie PC w C kilka lini kodu się napisze do testowania ciągu bajtów z pliku jako bity tą wspomnianą metodą Monte Carlo i porówna wyniki z innymi potencjalnymi źródłami losowości, w tym z innymi programowymi RNG...
  • Poziom 43  
    Mi się pomysł ze zbieraniem danych z niepodłączonego pinu nigdy nie podobał.
    Taki pin bardzo łatwo złapie jakieś okresowe zakłócenia i losowość będzie kiepska.
    Ja bym tam wstawił generator sinusoidalny na przykład (nawet na 1 tranzystorze). A najlepiej kilka o różnych częstotliwościach i sumował ich przebiegi.
    Albo dał diodę Zenera jak źródło szumu i wzmacniacz do tego.
  • Poziom 16  
    Z ciekawości mam zamiar to sprawdzić-wlutuję tam kawałki odciętych drucików od rezystorów do tych 2óch ADC i zobaczę jaka wartość PI wyjdzie ;)

    Później wstawię na chwilę do testów halotron czujnik analogowy SS495A-jest fajny bo wystarczy zasilanie 5V podpiąć i 3ci pin prosto do uP i tam w okolicy połowy napięcia zasilania powinno być jak nie ma zewnętrznego pola magnetycznego, no ale Ziemia jakieś tam ma, ale może to będzie nieco zakłócane przez różne urzadzenia w okolicy-jako eksperyment to traktuję...

    Nad drugi ADC fotorezystor LDR oświetlony n ieco tymi diodami co są w środku.

    Póki co mam tam zasilacz impulsowy z sieci 230VAC więc wyjście stabilizatora może lekko nawet nieco siadać bo kilkadziesiąt mA tam maksymalnie da się pociągnąć, więc to też nieco zakłóci te pomiary podczas załączania diód, ale tam praktycznie tylko pozycję potencjometrów bedę czytał przed załączeniem zgrzewania, więc jak to nieco siądzie to z tego co sprawdzałem niewiele, ale odczyty ADC do generatora będą nieco mniej stabile jak zrobię Vref VCC więc chyba trochę chaotyczności pojawi się w tym układzie tym bardziej że zasilanie w sieci domowej jest takie sobie i coś tam może się przedostawać.

    Żeby mieć porównanie z czymś lepszym na początek prymitywne niepodpięte piny z antenkami małymi ;)
  • Poziom 16  
    Kilka lini kodu w C na AVR ATTiny może zdziałać cuda

    Funkcja losująca ten bit jest prosta:
    Cytat:

    // TRNG functions
    static uint8_t trng_bit() {
    uint8_t bit;

    bit= (adc_get(ADCTRNG0)^adc_get(ADCTRNG1)^adc_get(ADCTRNG2)^adc_get(ADCTRNG3)) & 0x1;

    return bit;
    }

    static uint32_t trng_bits(uint8_t n) {
    uint32_t bits= 0;
    uint8_t i;

    for(i=0;i<n; i++ ) {
    bits=(bits<<1);
    bits|= trng_bit();
    }

    return bits;
    }

    static uint8_t trng_hex() {
    return (uint8_t)trng_bits(4);
    }

    static uint8_t trng_byte() {
    return (uint8_t)trng_bits(8);
    }
    // End of TRNG functions


    A w pętli głównej programu ok. 4-5 kHz takich bitów powinno się uzyskać, przy ADC 250 kHz i systemowym 8 MHz:
    Cytat:

    // new random bit
    abit= trng_bit();

    // Setup output for PWM
    aout= abit;

    // Count number of random bits
    acount++;
    } // End of for TRNG loop


    Przerwanie ustawia co ok. 1ms nową wartość wylosowanego bitu na PB1
    Cytat:

    // Clock click @ 1ms (1000 Hz) for F_CPU 1,4,8 MHz
    // NOTE: interupt vector @ $004
    ISR(TIMER1_OVF_vect) {

    // Time in miliseconds
    time_ms++;
    clock_ms++;
    clock_pwm_ms++;


    // Output bit
    if(aout==0 ) {
    // Clear
    if(OUTIS ) { PORTB &= ~(1<<OUTPIN); }
    } else {
    // Set
    if(OUTIS ) { PORTB |= (1<<OUTPIN); }
    }


    i... TRNG nawet najprostrzej wersji udało się uruchomić i widać, że generuje na pinie PB1 losowe impulsy z ustawioną czestotliwością 1kHz.
    Co ciekawe pomiar napięć na ADC ustawionych w ten sposób na input i z wyłączeniem cyfrowego wejścia:
    Cytat:

    // Change for ADC input from TRNG1
    DDRB &= ~(1<<TRNG1PIN);
    PORTB &= ~(1<<TRNG1PIN);
    // Disable digital input
    DIDR0 |= (1<<ADCTRNG1D);

    na pinach ADC nie podłączonych do niczego pokazuje mi przy napięciu zasilania ok. 4.96V wartości ok. 0.185V, na drugim 0.213V-to normalne?
    Nigdy nie zwracałem na to uwagi, bo zwykle te wolne piny są rezystorem do masy ściągnięte.
    Ale wygląda na to że nawet tak prymitywna metoda daje szalejące napięcie mierzone miernikiem na PB1 w okolicy 2.5V, bo losowo 0V i 5V jest na tym pinie ustawiane mam nadzieję że z prawdopodobieństwem 0.5 ;)

    W zasadzie program gotowy i wsad pod różne PCB w zasadzie ten sam do łączenia XORem odczytów z kilku ADC.
    Można bawić się z różnymi źródłami losowości poprzez podpięcie ich pod te 3y ADC w tym ATTiny85.
    Testy jakości generowanych bitów przeprowadzę po podłączeniu do PCta tego wyjściowego PB1 za pomocą optycznie izolowannego złącza-prawdopodobnie do starego laptopa przez LPT się wepnę za pomocą takiego optoizolatora zrobionego kiedyś z galwaniczną izolacją działającego spokojnie do kilku kHz.

    Sam sygnał z diody pulsującej w układzie takim czujnikiem światłą (LDR) wpinanym do... wejścia mikrofonowego laptopa
    TRNG z użyciem 4ech ADC Atmel AVR-czujnika Halla i temperatury
    za pomocą np. xoscope można sobie oglądnąć na dużym ekranie :)
  • Poziom 16  
    Przyszedł czas na testy tego TRNG i udało się znaleźć gotowe pakiety do testowania, tyle że ten który najbardziej mnie interesował czyli upubliczniony przez NIST
    Random Number Generation Technical Working Group (RNG-TWG) dostępny w ostatniej wersji chyba jaką znalazłem pod tym adresem:
    http://csrc.nist.gov/groups/ST/toolkit/rng/documents/sts-2.1.1.zip
    ładnie się kompiluje bezproblemowo, ale... próba załadowania swojego pliku z danymi uruchomienie jakiegokolwiek testu kończy mi się takim dziwnym komunikatem:
    Cytat:
    MAIN: Could not open freq file: <experiments/AlgorithmTesting/freq.txt>

    Całość wywołania poniżej (wygenerowałem 8 mln bitów z Linuxowego /dev/urandom i zapisałem w /tmp/testnist8Mb.rng )
    Cytat:

    nistrt]$ ./assess 8000000
    G E N E R A T O R S E L E C T I O N
    ______________________________________

    [0] Input File [1] Linear Congruential
    [2] Quadratic Congruential I [3] Quadratic Congruential II
    [4] Cubic Congruential [5] XOR
    [6] Modular Exponentiation [7] Blum-Blum-Shub
    [8] Micali-Schnorr [9] G Using SHA-1

    Enter Choice: 0


    User Prescribed Input File: /tmp/testnist8Mb.rnd

    S T A T I S T I C A L T E S T S
    _________________________________

    [01] Frequency [02] Block Frequency
    [03] Cumulative Sums [04] Runs
    [05] Longest Run of Ones [06] Rank
    [07] Discrete Fourier Transform [08] Nonperiodic Template Matchings
    [09] Overlapping Template Matchings [10] Universal Statistical
    [11] Approximate Entropy [12] Random Excursions
    [13] Random Excursions Variant [14] Serial
    [15] Linear Complexity

    INSTRUCTIONS
    Enter 0 if you DO NOT want to apply all of the
    statistical tests to each sequence and 1 if you DO.


    Enter Choice: 01

    P a r a m e t e r A d j u s t m e n t s
    -----------------------------------------
    [1] Block Frequency Test - block length(M): 128
    [2] NonOverlapping Template Test - block length(m): 9
    [3] Overlapping Template Test - block length(m): 9
    [4] Approximate Entropy Test - block length(m): 10
    [5] Serial Test - block length(m): 16
    [6] Linear Complexity Test - block length(M): 500

    Select Test (0 to continue): 0

    MAIN: Could not open freq file: <experiments/AlgorithmTesting/freq.txt>

    Ktoś używał tego narzędzia do testowania generatorów liczb losowych może?
    Chyba te 8 mln bitów to za mało (jak widać na innym prostym teście), no ale chodziło o to żeby w ogóle po kompilacji uruchomić te testy.

    Nieco zagmatwane, a nie miałem wczoraj czasu na debugowanie tego i przeglądanie kodu skąd ten błąd się bierze.

    Więc znalazłem coś prostrzego na początek:
    ENT - A Pseudorandom Number Sequence Test Program
    Ten soft już bezproblemowo się uruchamia i dla tego generatora wbudowanego w /dev/urandom Linux'a mamy coś takiego dla 64Mb:
    Cytat:

    $ randomenttest /tmp/testnist64Mb.rnd -b

    Entropy = 1.000000 bits per bit.

    Optimum compression would reduce the size
    of this 64000000 bit file by 0 percent.

    Chi square distribution for 64000000 samples is 2.34, and randomly
    would exceed this value 12.58 percent of the times.

    Arithmetic mean value of data bits is 0.4999 (0.5 = random)
    Monte Carlo value for Pi is 3.140844785 (error 0.02 percent).
    Serial correlation coefficient is 0.000135 (totally uncorrelated = 0.0).

    Dla pliku 128MB estymacja PI jest już na poziomie:
    Cytat:

    $ make test
    randomenttest test.rnd -b
    Entropy = 1.000000 bits per bit.

    Optimum compression would reduce the size
    of this 1073741824 bit file by 0 percent.

    Chi square distribution for 1073741824 samples is 0.88, and randomly
    would exceed this value 34.71 percent of the times.

    Arithmetic mean value of data bits is 0.5000 (0.5 = random).
    Monte Carlo value for Pi is 3.141600477 (error 0.00 percent).
    Serial correlation coefficient is 0.000010 (totally uncorrelated = 0.0).

    Czyli PI różnie się o ok. 0.00001 od poprawnej wartości.

    Zrobiłem póki co te testy na nie do końca chyba TRNG generatorze z /dev/urandom w celu porównania później z odczytami z mojego TRNG na ATTiny.

    Na tej stronie jako ciekawy test proponują również zrobienie obrazka bitmapy z generatora i też czasami na pierwszy rzut oka już widać, że mamy do czynienia z nie losowymi bitami:
    Are the Numbers Really Random?

    Szkoda, że póki co nie udało się uruchomić tego testu NIST, więc jakby ktoś tego używał i wie w czym może być problem to dajcie znać, a może mi się uda po analizie kodu źródłowego poprawić ten program, ale na początek ten drugi test i ew. obrazka bitmapy wystarczy chyba,
    a dla relaksu można poczytać sobie ten dokument NIST A Statistical Test Suite for the Validation of Random Number Generators and Pseudo Random Number Generators for Cryptographic Applications, który opisuje przeprowadzane testy w ich narzędziu ;)

    Update: Wygląda na to że problem był z uprawnieniami, ponieważ użytkownik uruchamiający te testy nie miał praw do pisania i zakładania nowych plików, a ten komunikat był wprowadzający w błąd, bo nie precyzował czy otwiera do czytania czy pisania a w programie jest otwierany do pisania ;)
    Cytat:

    sprintf(freqfn, "experiments/%s/freq.txt", generatorDir[option]);
    if ( (freqfp = fopen(freqfn, "w")) == NULL ) {
    printf("\t\tMAIN: Could not open freq file: <%s>", freqfn);
    exit(-1);
    }

    Testy NIST się uruchamiają, pozostało poczytać jak sensownie parametry podać i interpretować ich wyniki poprawnie.
  • Poziom 1  
    aneuro w jaki sposób rozwiązałeś ten problem z uprawnieniami plików ?