2017-03-24 6 views
3

Ich habe ein Problem versucht, die OpenSSL Shared Library (libcrypto) kompiliert verwenden FIPS fähig auf einem MIPS Gerät.
ich die FIPS Object Module und dann die OpenSSL-Bibliothek auf folgende Weise Cross zusammengestellt (zusammenfassend):FIPS Capable OpenSSL Quer zusammengestellt: incore Fingerabdruck Ausgabe

export FIPS_SIG=<my_path>/incore 
./config fips --with-fipsdir=<my_path>/fips-2.0 
make depend 
make 
make install 

Ich habe alle Schritte erforderlich, so dass ich bin in der Lage, die Bibliothek zu kompilieren und zu installieren.
Das Problem tritt auf, wenn ich versuche, die FIPS_mod_set(1) API von einer Anwendung auszuführen, die die OpenSSL-Bibliothek verbindet.
Die FIPS-Modus Initialisierung dieser Fehler fehlschlägt Empfang:

2010346568:error:2D06B06F:lib(45):func(107):reason(111):NA:0: 

den FIPS-Code debuggen, fand ich, dass das Problem in der FIPS_check_incore_fingerprint(void) Funktion ist:
Check memcmp(FIPS_signature,sig,sizeof(FIPS_signature)) ausfällt.
Tiefer im Debug ich, dass derjenige, so habe ich den Zweifel entdeckt FIPS_signature Wert bleibt der Standard, dass die incore Skript, durch das fipsld Dienstprogramm genannt, nicht richtig den Fingerabdruck ist die Einbettung innerhalb der OpenSSL geteilt Objekt.
Wie kann ich überprüfen, ob das incore Skript den Fingerabdruck in das gemeinsame Objekt eingebettet hat?
Wie kann ich den erwarteten Fingerabdruck drucken?
Muss ich das Skript incore anpassen? (Ich nehme an, es ist nicht erlaubt)
Haben Sie einen Vorschlag?
Vielen Dank!

S.S .: Ich bin Cross-Compiling mit einem x86-Linux-Maschine.

+0

Nur ein FYI ... Nur eine MIPS-Plattform validiert wurde. Es ist die VxWorks 6.8-Betriebsumgebung mit einem TI TNETV1050-Prozessor. Siehe auch [OpenSSL FIPS 140-2 Sicherheitsrichtlinie, v 2.0. S. 9-10] (https://www.openssl.org/docs/fips/SecurityPolicy-2.0.pdf). – jww

+0

[hier] (https://stackoverflow.com/questions/35664412/unable-to-build-a-working-fips-capable-openssl-on-hp-ux) ist eine Frage, die ich vor einiger Zeit gefragt, wann ich hatte ein irgendwie verwandtes Problem. Zu Debugging-Zwecken können Sie jede Datei ändern (ich habe es für _fips \ _premain.c_, _fips.c_, _fipsld_ gemacht), aber beim Erstellen der "offiziellen" Version dürfen Sie nichts ändern (eigentlich gibt es viele Einschränkungen). Stellen Sie außerdem sicher, dass Ihr Plattform/Architektur-Paar unterstützt wird. – CristiFati

+0

Es gibt eine Menge Informationen, die in der Frage fehlen, die nützlich sein könnte. Anstatt das mögliche Problem zu erraten, wäre vielleicht das [Benutzerhandbuch für das OpenSSL FIPS-Objektmodul v2.0] (https://www.openssl.org/docs/fips/UserGuide-2.0.pdf) ein guter Anfang. – jww

Antwort

1

Ich habe das Problem gefunden! Ich werde versuchen, den gesamten Debugging-Prozess und die Lösung zu erklären.

BESCHREIBUNG:

Wenn OpenSSL konfiguriert ist FIPS der Lage sein, bei der Erstellung der Makefile ein Dienstprogramm aufruft, fipsld, die sowohl die Prüfung der Module FIPS Objekt ausführt und erzeugt die neue HMAC -sha-1 verdaut für die Anwendung ausführbar (wie in der offiziellen OpenSSL Bedienungsanleitung https://www.openssl.org/docs/fips/UserGuide-2.0.pdf erklärt)

der fipsld Befehl erfordert, dass der CC und FIPSLD_CC Umgebungsvariablen gesetzt werden, wobei Letzteres Vorrang hat.

libcrypto$(SHLIB_EXT): libcrypto.a fips_premain_dso$(EXE_EXT) 
    @if [ "$(SHLIB_TARGET)" != "" ]; then \ 
     if [ "$(FIPSCANLIB)" = "libcrypto" ]; then \ 
      FIPSLD_LIBCRYPTO=libcrypto.a ; \ 
      FIPSLD_CC="$(CC)"; CC=$(FIPSDIR)/bin/fipsld; \ 
      export CC FIPSLD_CC FIPSLD_LIBCRYPTO; \ 
     fi; \ 
     $(MAKE) -e SHLIBDIRS=crypto CC="$${CC:-$(CC)}" build-shared && \ 
     (touch -c fips_premain_dso$(EXE_EXT) || :); \ 
    else \ 
     echo "There's no support for shared libraries on this platform" >&2; \ 
     exit 1; \ 
    fi 

Dann wird das fipsld Dienstprogramm ruft ein Shell-Skript, incore, verwendet einzubetten die FIPS Object Module erwarteten Fingerabdruck im OpenSSL gemeinsam genutztes Objekt:
Im Makefile werden Sie so etwas wie dieses finden.Es ist wichtig, den incore Weg über FIPS_SIG env Variable angeben, zum Beispiel:

export FIPS_SIG=$PWD/openssl­fips­2.0/util/incore 

DEBUGGEN:

Debuggen des incore Skript, konnte ich sehen, dass das Skript versucht, die Unterschrift in einzubetten das gemeinsame Objekt am Offset 0x001EE6B0 während das Symbol FIPS_signature innerhalb des gemeinsamen Objekts wurde an einem anderen Offset, genauer bei 0x001F0630:

objdump -t libcrypto.so.1.0.0 | grep FIPS_signature 
001f0630 g  O .data 00000014    FIPS_signature 

readelf -a libcrypto.so.1.0.0 | grep FIPS_signature 
    870: 001f0630 20 OBJECT GLOBAL DEFAULT 18 FIPS_signature 
    3925: 001f0630 20 OBJECT GLOBAL DEFAULT 18 FIPS_signature 

Des Weiteren das gemeinsame Objekt Dumping ich nicht in der Lage war, die erzeugte Signatur am Offset 0x001EE6B0 so kam ich zu dem Schluss, dass das gemeinsame Objekt nach dem Verfahren von einigen Einbettung Signatur bearbeitet wurde zu finden anderer Prozess.

LÖSUNG:

I wurde in der folgenden Weise formatiert ein Paket Makefile für das OpenSSL Paket unter Verwendung:

$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) 
    <options> 
    all 
$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) 
    <options> 
    build-shared 
rm $(PKG_BUILD_DIR)/libssl.so.*.*.* 
$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) 
    <options> 
    do_linux-shared 
$(MAKE) -C $(PKG_BUILD_DIR) 
    <options> 
    install 

Wie vermutet, make build-shared und make do_linux-shared Befehle waren verantwortlich für das Ändern des gemeinsamen Objekts auf die falsche Weise.
Beachten Sie, dass build-Shared machen wurde ohne Verwendung der richtigen Umgebungsvariablen genannt.

ich das Paket Makefile geändert:

$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) 
    <options> 
    all 
$(MAKE) -C $(PKG_BUILD_DIR) 
    <options> 
    install 

Nun ist die FIPS_check_incore_fingerprint(void) Funktion gibt mit Erfolg und alles funktioniert prima!

HINWEIS:

Die folgende Anleitung für Android-Geräte ist sehr nützlich, um die richtige Lösung zu finden. https://wiki.openssl.org/index.php/FIPS_Library_and_Android

+0

"Ich konnte sehen, dass das Skript versuchte, die Signatur in das gemeinsame Objekt mit dem Offset 0x001EE6B0 einzubetten" Würde es Ihnen etwas ausmachen zu erklären, wie Sie das gefunden haben? Vielen Dank! – zachwhaley

+1

Ich druckte den Offset, der innerhalb des incore-Skripts verwendet wurde (patchen den Code), und ich verglich den Offset mit dem, der aus der objdump-Inspektion resultierte – neoben

Verwandte Themen