Skocz do zawartości

Moduł Szyfrowania USB


Pomocna odpowiedź

Podoba Ci się ten projekt? Zostaw pozytywny komentarz i daj znać autorowi, że zbudował coś fajnego!

Masz uwagi? Napisz kulturalnie co warto zmienić. Doceń pracę autora nad konstrukcją oraz opisem.

44 minuty temu, H1M4W4R1 napisał:

Blue Pill / Black Pill

Jako, że moje Nucleo32 nie posiadały wsparcia USB poszedłem w stronę Blue/Black Pilla. Niestety, wszystkie zakupione modele nie lubiły się z moim komputerem i zwracały błędy enumeracji. Po około dwóch tygodniach zrezygnowałem z męczenia się z "Pastylami" i zacząłem szukać alternatywnego rozwiązania.

Być może miałeś wersje z rezystorem 10k zamiast 1.5k dla vusb.

  • Pomogłeś! 1
Link to post
Share on other sites
(edytowany)
2 godziny temu, Zealota napisał:

Być może miałeś wersje z rezystorem 10k zamiast 1.5k dla vusb.

152, więc raczej obstawiałbym niskiej jakości rezonator kwarcowy...

Raspi Pico

Aktualnie czekam na moje RasPico (Raspberry Pi Pico), podobno mają 133MHz i dwa rdzenie - wtedy mógłbym wyrzucić USB na jeden rdzeń, a algorytm na drugi rdzeń, więc urządzenie w teorii mogłoby osiągnąć pełną przepustowość USB Full Speed (syntetyczne szyfrowanie na STM32 wykazywało wynik ok. 600-800kB/s przy 80MHz). A zarazem byłoby taniej 😄 Low Level USB (RasPico) MultiCore

Upgrade

W międzyczasie bawię się z upgradem tego urządzenia, by mogło przechowywać w swojej pamięci zaszyfrowane hasła (PCB Revision 3, które nie jest jeszcze publicznie dostępne), aczkolwiek raczej testy na Pico dostaną wyższy priorytet... (P.S. nowa płytka też jest kompatybilna w 100% z starym firmware)

image0.thumb.jpg.b3fcea930f383d9614fbd973223c0e7d.jpg

Praktycznie to jest to samo, tylko doszła pamięć SPI flash z rezystorami 22R w celu redukcji ewentualnych zakłóceń. Ta wielka płachta czystej płytki jest tylko by urządzenie dobrze siedziało w obudowie, tam będzie wlutowane złącze kątowe SWD+SWO.

A i po zamówieniu płytek poprawiłem te ścieżki SWD i są bliżej... Tak to jest jak się projektuje płytkę przysypiając...

Z dodatkowych rad

  • Jeżeli używacie USB Full Speed, to naprawdę praktycznie nie musicie się przejmować impedancją... zwykle będzie działać. Jeżeli stosujecie bardzo krótkie ścieżki (rzędu 0.5mm od wtyku do MCU) to USB zwykle dobrze działa. (NIE STOSOWAĆ DO USB HS i SS, ANI DŁUGICH ŚCIEŻEK 1.5cm+)
  • Dobrym rozwiązaniem jest umieszczenie rezystorów 0R na ścieżkach USB - zawsze można je podmienić na 22R, jak coś nie działa i często to wystarczy by naprawić całkiem sporą ilość problemów z enumeracją. (Czasem stosuje się 20R, ale 22R łatwiej dostać)
  • Uważajcie na umieszczanie kondensatorów przy mikrokontrolerze - zwykle umieszczajcie je jako pierwsze, gdyż inaczej wasze MCU może nawet się nie zbootować do DFU 😄
  • STM32 obsługuje USB DMA w sposób zautomatyzowany, nie trzeba się tym przejmować
  • Jeżeli macie złe napięcie na zegarze pamięci W25QxxJVSIG to prawdopodobnie macie ustawioną złą ilość bitów w mikrokontrolerze (np. Motorola 4bit zamiast Motorola 8bit)... Taki dziwny mankament mi się przytrafił 😉

Zobaczymy jak pójdzie z Pico... postaram się wrzucić update jak tylko się z nim uporam.

Edytowano przez H1M4W4R1
SPI nie QSPI...
  • Lubię! 1
Link to post
Share on other sites

Świetny projekt i co najważniejsze przeprowadzony od pomysłu do gotowego urządzenia w estetycznej obudowie! Gratuluję!

Czy po wpisaniu błędnego hasła urządzenie zwraca błąd czy odszyfrowuje dane błędnym kluczem?

Pozdr!

  • Lubię! 2
Link to post
Share on other sites
(edytowany)
9 godzin temu, MR1979 napisał:

Świetny projekt i co najważniejsze przeprowadzony od pomysłu do gotowego urządzenia w estetycznej obudowie! Gratuluję!

Czy po wpisaniu błędnego hasła urządzenie zwraca błąd czy odszyfrowuje dane błędnym kluczem?

Pozdr!

Niestety urządzenie nie ma w danych sumy kontrolnej, wiec deszyfruje dane, tylko wynik operacji jest taki jakby zostały zaszyfrowane dwoma różnymi hasłami. Teoretycznie implementacja CRC do szyfrowania nie jest trudna, ale należy mieć na uwadze, że VMPC jest szyfrem strumieniowym i symetrycznym, więc dodanie CRC jest potencjalnym ryzykiem łatwiejszego deszyfrowania. 
Aktualne API jest bardziej zorientowane low-level, więc technicznie na poziomie high-level wystarczy zsumować bajty pliku do uint32 i dodać na końcu sekwencji po czym podczas deszyfrowania porównać wynik sumy CRC i zdeszyfrowanych bajtów by sprawdzić czy hasło było poprawne.

Ważne jest też to, by dane na początku pliku w miarę możliwości się nie powtarzały, o tym można przeczytać więcej w dokumentacji VMPC.

Update

Dodałem sumę kontrolną w postaci komendy 0x10.

realterm_fSujzTgEo5.thumb.png.c4903d94e3934e51ecc39c7827f31a38.png

Na załączonym obrazku pierwsze 4B w linijce to zaszyfrowane dane przesłane do urządzenia, pozostałe 8B to suma kontrolna. Urządzenie posiada dwie 32-bitowe sumy - jedna sumuje dane wejściowe, druga wyjściowe, wystarczy zamienić je miejscami, by sprawdzić poprawność deszyfrowania względem sumy uzyskanej z szyfrowania. Suma nie jest elementem, który jest szyfrowany, więc korzystanie z niej pozwala na łatwiejsze złamanie klucza... ale jednak nadal to będzie dość długi czas 🙂

Update jest na Git

Edytowano przez H1M4W4R1
Update, cmd_0x10.h
  • Lubię! 2
Link to post
Share on other sites

Cześć,

projekt fajny, tylko nie rozumiem dlaczego nie wybrałaś wersji MCU (STM32 serii L4 lub F4) ze sprzętowym wsparciem dla AES'a z 265 bitowym kluczem (akcelerator) i sum kontrolnych (np. MD5). Mógłbyś wtedy osiągnąć dużo większe prędkości szyfrowania (no i masz gotowe API - bibliotekę kryptograficzną gotową). Patrz link:

https://www.st.com/content/ccc/resource/training/technical/product_training/8b/70/87/cd/04/6e/41/ee/STM32L4_Security_AES.pdf/files/STM32L4_Security_AES.pdf/jcr:content/translations/en.STM32L4_Security_AES.pdf

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwiG-Kncq8juAhUC-hQKHTKEB0UQFjAAegQIARAC&url=https%3A%2F%2Fwww.st.com%2Fresource%2Fen%2Fuser_manual%2Fdm00215061-stm32-crypto-library-stmicroelectronics.pdf&usg=AOvVaw0s1IaDcCcsGxa6ndE6YPhG

Pozdrawiam

 

  • Lubię! 1
Link to post
Share on other sites

@FlyingDutch

Po pierwsze chciałem zachować kompatybilność z aktualnym systemem, którego używałem. Technicznie to urządzenie ze sprzętową akceleracją może się bujać do 40MB/s a w ASIC pewnie parę GB/s 🙂

Po drugie chciałem spróbować czegoś nietypowego - Arduino np. nie ma wsparcia dla AES no i tutaj ląduje problem. Dodatkowo AES jest znacznie bardziej podatny na ataki niż VMPC. No i mamy wynik.

AES / VMPC według kryptoanaliz VMPC jest bezpieczniejsze i uruchomisz to nawet na MCU z 1980 roku

  • Lubię! 2
Link to post
Share on other sites

@MR1979 

Wróćmy do początku - urządzenie nie powstało docelowo, by zastąpić szyfrowanie standardowymi algorytmami (AES, RSA etc.), których używam w szyfrowaniu danych wrażliwych, a bardziej do szyfrowania plików mniej podatnych na zainteresowanie hakerów np. arkusz techniczny projektu do realizacji (zwykle gier mobilnych) [...oraz by nauczyć się designu PCB / schematic capture]. Stąd zrezygnowałem z AES, a że chciałem też sprawdzić czy Arduino da radę zaszyfrować pliki. Wyszło co wyszło - wyszedł dowód, że nawet potencjalnie słabe MCU jest w stanie szyfrować dane z dość przyzwoitą prędkością - ten moduł po przeniesieniu na UART jest w stanie bez problemu obsługiwać dwukierunkowe szyfrowanie transmisji np. LoRa - tutaj AES CTR z swoją podatnością na duplikację kluczy zbytnio się nie nadaje, za to VMPC jak najbardziej, gdyż był projektowany jako szyfrowanie strumieniowe.

A Pi Pico ma dobre API do nauki USB LL, stąd padło na nie (i zarazem dwa rdzenie, więc dwie pieczenie na jednym ogniu). Jestem z tych osób co nie tworzą, by czegoś używać, tylko tworzą by tworzyć...

Punkt 1 - SHA można używać podczas szyfrowania danych na procesorze w komputerze (wtedy urządzenie służy wyłącznie jako KSA), implementacja SHA by zabrała znaczną ilość mocy obliczeniowej z urządzenia

Punkt 3 - VMPC KSA3

Punkt 5 - to jest oficjalna implementacja VMPC 🙂 I gdybyśmy zawsze stosowali się do standardów to byśmy nadal żyli w prehistorii 😉

Punkt 7 - zawsze można wylutować (sarkazm)

Punkt 4 - oczywiście do muchy strzelam z rusznicy a do czołgu z pistoletu... i nie używam gwoździ tylko wszystko idzie na wkręty

  • Lubię! 2
Link to post
Share on other sites
9 minut temu, H1M4W4R1 napisał:

@MR1979 

Wróćmy do początku - urządzenie nie powstało docelowo, by zastąpić szyfrowanie standardowymi algorytmami (AES, RSA etc.), których używam w szyfrowaniu danych wrażliwych, a bardziej do szyfrowania plików mniej podatnych na zainteresowanie hakerów np. arkusz techniczny projektu do realizacji (zwykle gier mobilnych) [...oraz by nauczyć się designu PCB / schematic capture]. Stąd zrezygnowałem z AES, a że chciałem też sprawdzić czy Arduino da radę zaszyfrować pliki.

Cześć,

ale przecież użyłeś STM32 z serii L4 - cytat:

Cytat

Procesor: STM32 L432 KBU6 (80MHz)

Właśnie w tej serii są także modele MCU ze sprzętowym wsparciem dla kryptografi (wspomniany AES). Bardziej chodzi mi nawet o sprawdzoną bibliotekę kryptograficzną z np. algorytmami bezpiecznej wymiany kluczy. Tak jak kolega @MR1979 napisał staram się unikać pisania własnego kodu do kryptografi ze względu na niznaną podatność tego kodu na ataki. Oczywiście w tym projekcie, gdy piszesz to dla siebie do ochrony mniej istotnych plików nie ma to wielkiego znaczenia. Projekt oceniam bardzo dobrze.

Pozdrawiam

  • Lubię! 2
Link to post
Share on other sites

@FlyingDutch

Okej rozpiszę kroki kolejno:

  1. Powstanie pomysłu
  2. Prototyp na Arduino Nano
  3. Arduino jest dość wolne (wersja lekka algorytmu chodziła max 130kB/s w syntetycznym benchmarku)
  4. Szukanie alternatywnych rozwiązań - ATMega? Cypress?
  5. Wylądowałem na stronie STM dla wsparcia starupów i studentów
  6. Dostałem STM32
  7. Przetestowałem na Nucleo G031, wyniki były obiecujące (500kB/s w syntetycznym benchmarku, 64MHz)
  8. Plan przerzucenia tego na USB... jednak UART na STM ma limit 115.2kbps
  9. Testy na Pill'sach - nieudane
  10. Projekt płytki
  11. Firmware i testy, dopracowywanie

Stąd padło na STM32 - po prostu "tak wyszło". Pierwsza wersja algorytmu powstała (nie pamiętam dokładnie), ale gdzieś w środku listopada (14-21) 2020 roku i była napisana pod Arduino Nano v3. W skrócie - pierwsza wersja była na Arduino, a że potem trafiłem na STM to "głód wiedzy" chciał sprawdzić jak ten algorytm zachowa się na STM32 - będzie ok. 5-6 razy wydajniejszy.

P.S. Polecam brać poprawkę na to, że często niezbyt dokładnie się wysławiam i zostawiam niedopowiedzenia... 

  • Lubię! 2
Link to post
Share on other sites

Usunąłem 2 posty z tego tematu ze względu na to, że jedne z nich nie był zgodny z PPF. Usunięte posty można znaleźć w tym miejscu - linkuje, bo post ten nie jest zgodny z PPF, ale jednak (między wierszami) można wyczytać z niego sporo technicznych kwestii.

Link to post
Share on other sites
Zarejestruj się lub zaloguj, aby ukryć tę reklamę.
Zarejestruj się lub zaloguj, aby ukryć tę reklamę.

jlcpcb.jpg

jlcpcb.jpg

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

Dołącz do dyskusji, napisz odpowiedź!

Jeśli masz już konto to zaloguj się teraz, aby opublikować wiadomość jako Ty. Możesz też napisać teraz i zarejestrować się później.
Uwaga: wgrywanie zdjęć i załączników dostępne jest po zalogowaniu!

Anonim
Dołącz do dyskusji! Kliknij i zacznij pisać...

×   Wklejony jako tekst z formatowaniem.   Przywróć formatowanie

  Dozwolonych jest tylko 75 emoji.

×   Twój link będzie automatycznie osadzony.   Wyświetlać jako link

×   Twoja poprzednia zawartość została przywrócona.   Wyczyść edytor

×   Nie możesz wkleić zdjęć bezpośrednio. Prześlij lub wstaw obrazy z adresu URL.

×
×
  • Utwórz nowe...

Ważne informacje

Ta strona używa ciasteczek (cookies), dzięki którym może działać lepiej. Więcej na ten temat znajdziesz w Polityce Prywatności.