Symptoom

Deze instructies zijn alleen voorbereid voor systeem x240 M5. Ondersteuning voor Remote Physical Presence is toegevoegd in UEFI C4E132H Revisie 2.50.

Om "Secure Boot" op een server in te schakelen, is het niet nodig om het systeem fysiek te openen of interne DIP-switchinstellingen te wijzigen. UEFI-installatie biedt de mogelijkheid om op afstand fysieke aanwezigheid te bevestigen. Gebruikers kunnen ook handmatig de DIP-switch 6 bit 2 instellen om fysieke aanwezigheid hardwarematig te bevestigen, maar het wordt om veiligheidsredenen afgeraden om de fysieke aanwezigheid bevestigd te laten nadat het systeem is opgestart in een besturingssysteem.

Stap 1:
Start de server op in het UEFI Setup-scherm. Blader naar systeeminstellingen --> Beveiliging --> Configuratie van fysiek aanwezigheidsbeleid.

In de standaardmodus kunnen gebruikers verwachten dat Physical Presence Policy ingeschakeld en grijs is. Gebruikers zien Physical Presence State = De-asserted.
Opmerking: Als om welke reden dan ook Physical Presence Policy is uitgeschakeld, dan zal het tabblad "toggle Remote Physical Presence Assert" grijs zijn. Om het beleid te kunnen voortzetten, moet het eerst worden ingeschakeld. Hiervoor moet de fysieke aanwezigheid van de hardware worden ingesteld met DIP-switch 6 bit 2 en moet er opnieuw worden opgestart om de installatie te starten. Vervolgens kunt u het Physical Presence Policy inschakelen.
Deze functie biedt beheerders een extra beveiligingsfunctie om het beleid voor fysieke aanwezigheid uit te schakelen om externe bewering van fysieke aanwezigheid te voorkomen. Om veiligheidsredenen moet de fysieke aanwezigheid van de hardware worden verwijderd door DIP-switch 6 bit 2 uit te schakelen zodra het beleid is uitgeschakeld.

Stap 2:
Scroll naar beneden naar 'toggle Remote Physical Presence Assert', selecteer dit en druk op de Enter-toets.
Gebruikers zullen zien dat de "physical Presence State" verandert in asserted. Asserting en de-asserting vereisen geen reboot om van kracht te worden.

Stap 3:
Druk nu op de Esc-toets om één niveau terug te gaan en ga naar: Beveiliging > Tabblad Secure Boot Configuration.

Mogelijk moet u op de status Fysieke aanwezigheid vernieuwen drukken om de huidige waarde van Fysieke aanwezigheid weer te geven.

Stel nu de beveiligingsopstartconfiguratie in --> Beveiligd opstarten --> wijzig dit van Uitgeschakeld naar Ingeschakeld.

Gebruikers zien een pop-upprompt: "Weet u zeker dat u Secure Boot wilt inschakelen? Wilt u doorgaan? J/N << voer J in.

Stap 4:
Ga nu terug naar het tabblad Configuratie van fysiek aanwezigheidsbeleid en selecteer opnieuw --> 'Toggle Remote Physical Presence Assert' om de fysieke aanwezigheidsstatus ongedaan te maken.

Stap 5:
Druk op de 'Esc'-toets om naar het hoogste niveau van UEFI Setup te gaan, sla de instellingen op en start het systeem opnieuw op.

Dezelfde stappen kunnen ook worden gebruikt om beveiligd opstarten uit te schakelen.

Betrokken configuraties

Het systeem kan een van de volgende Lenovo servers zijn:

• Lenovo Flex System x240 M5 Compute Node, Type 9532, elk model

Deze tip is niet softwarespecifiek.

Deze tip is niet optiespecifiek.

Het systeem vertoont de hierboven beschreven symptomen.

Tijdelijke oplossing

Niet van toepassing.

Aanvullende informatie

Secure boot is bedoeld om te verzekeren dat alle uitgevoerde code vertrouwd en ondertekend is. In de standaardmodus zal Lenovo firmware alles wat geladen is in de UEFI-modus, met handtekening verifiëren.

Wanneer Secure Boot is geactiveerd, controleert het elk stukje software, inclusief de UEFI-drivers (Option ROM's) en het besturingssysteem, tegen databases met bekende goede handtekeningen. Als elk stukje software geldig is, voert de firmware de software en het besturingssysteem uit. De Secure Boot-functie voorkomt dus dat een adapterkaart wordt opgestart waarvan wordt vastgesteld dat deze een ROM bevat die niet overeenkomt met de verwachte handtekening.

Veilig opstarten wordt alleen ondersteund voor de UEFI-opstartmodus en niet voor de oude opstartmodus.

OEM's leveren hun drivers aan Lenovo die vervolgens worden opgenomen in de UEFI-firmware. Dit omvat de signature database (db), revoked signatures database (dbx) en de Key Enrollment Key database (KEK). Deze databases worden op het flashgeheugen opgeslagen tijdens de productie.

In de database met handtekeningen en de database met ingetrokken handtekeningen worden de ondertekenaars of image-hashes van UEFI-toepassingen, besturingssysteemladers (zoals Microsoft Operating System Loader of Boot Manager) en UEFI-stuurprogramma's vermeld die op de server kunnen worden geladen, en de ingetrokken images voor items die niet langer worden vertrouwd en mogelijk niet worden geladen.

De Key Enrollment Key-database is een aparte database met ondertekeningssleutels die kan worden gebruikt om de handtekeningendatabase en de ingetrokken handtekeningendatabase bij te werken. Microsoft vereist dat een bepaalde sleutel wordt opgenomen in de KEK-database, zodat Microsoft in de toekomst nieuwe besturingssystemen aan de handtekeningendatabase kan toevoegen of bekende slechte afbeeldingen aan de ingetrokken handtekeningendatabase kan toevoegen. Nadat deze databases zijn toegevoegd en na de laatste firmwarevalidatie en -tests, vergrendelt Lenovo de firmware tegen bewerken, behalve voor updates die zijn ondertekend met de juiste sleutel of updates door een fysiek aanwezige gebruiker die firmwaremenu's gebruikt, en genereert vervolgens een PK. De PK kan worden gebruikt om updates naar de KEK te ondertekenen of om Secure Boot uit te schakelen.

Over het algemeen is er een voorrangsvolgorde (van meest naar minst significant) van PK, KEK, db, dbx. Dat is:

- Om een KEK te updaten, heb je een handtekening met de juiste PK nodig.

- Om een db of dbx bij te werken, moet u een handtekening met de juiste PK of KEK hebben.

- Een PK is vereist om Secure Boot in te schakelen.

De beschrijving van de toetsen is belangrijk om de modi te begrijpen die we ondersteunen. Secure Boot heeft twee (2) modi: Standaard en Aangepast.

Met de standaardmodus kan een gebruiker gebruikmaken van certificaten die door Microsoft zijn ondertekend. Deze certificaten stellen UEFI in staat om te verifiëren dat alle optie-ROM's en besturingssystemen zijn ondertekend en geldig zijn. Ze omvatten zowel Windows als certificaten van derden voor Linux. In wezen staan we toe dat deze standaardwaarden in beveiligde opstartcertificaten worden gebruikt in onze standaardmodus. Dit omvat de ene PK, meerdere KEK, db en dbx.

Met de Custom Mode kan een gebruiker zijn eigen set sleutels installeren. De specificaties voor Secure Boot-status staan een boot toe in Custom Mode zonder een PK. Dit stelt een OS in staat een nieuwe PK te registreren die vervolgens wordt gebruikt om zijn eigen KEK, db en dbx te valideren.

De standaardinstelling voor de beveiligde opstartmodus is de Standaardmodus en de standaardinstelling voor beveiligd opstarten is Uitgeschakeld.

Fysieke aanwezigheid:
Physical Presence is een vorm van autorisatie om bepaalde TPM-functies uit te voeren. Deze autorisatie komt normaal gesproken van de platformoperator. Voor TPM 1.2-apparaten zijn de functies die fysieke aanwezigheid vereisen, de functies die provisioning- en reprovisioningbewerkingen uitvoeren, zoals het toestaan van eigendom en het wissen van eigendom wanneer de huidige eigenaarsautorisatiewaarde onbekend is. Voor TPM 2.0-apparaten is fysieke aanwezigheid gekoppeld aan bewerkingen die platformautorisatie vereisen, maar worden geïnitieerd door het besturingssysteem. Normaal gesproken kan platformautorisatie alleen worden gegeven door firmware, niet door het besturingssysteem. Er zijn twee methoden om fysieke aanwezigheidsautorisatie te bieden: de opdrachtmethode en de hardwaremethode. Deze twee methoden zijn gedefinieerd voor TPM 1.2-apparaten in de TPM 1.2 Main Specification en voor TPM 2.0-apparaten in de PC Client Platform TPM Profile Specification.

Hardwaremethode om fysieke aanwezigheid te bevestigen:
Een voorbeeld van een implementatie van de hardwaremethode is een DIP-switch op het systeembord die is aangesloten op een pin op de TPM. Het instellen van de switch zorgt ervoor dat de pin de polariteit verandert en dat de TPM zijn interne fysieke aanwezigheidsvlag instelt. Met deze hardwaremethode kunnen opdrachten die de indicatie van fysieke aanwezigheid vereisen op elk gewenst moment worden uitgevoerd (in de pre-OS-omgeving of vanuit de OS-omgeving), zolang de switch is ingesteld en, voor TPM 2.0, platformautorisatie beschikbaar is. Dit vormt een beveiligingsprobleem als de switch in de beweerde positie wordt gelaten.

Opdrachtmethode om fysieke aanwezigheid te bevestigen:
Het is in sommige gevallen niet haalbaar om een knop of schakelaar aan de buitenkant van het platform te plaatsen vanwege kosten, vormfactor, gebruik of toegankelijkheid. Om deze reden is een tweede methode gedefinieerd om fysieke aanwezigheid te bevestigen, de command-methode. Voor de command-methode presenteert firmware een gebruikersinterface (UI) om de gevraagde bewerking uit te leggen. Een fysiek aanwezige gebruiker bevestigt of weigert de bewerking door op een toets op het toetsenbord te drukken. De command-methode autoriseert vervolgens de TPM-opdracht om naar de TPM te worden verzonden. Er wordt geen verdere controle op fysieke aanwezigheid uitgevoerd in de TPM. De TPM voert de TPM-bewerking uit als de gebruiker deze via de UI heeft bevestigd. Een van de vereiste eigenschappen van de indicatie van fysieke aanwezigheid is dat deze moet worden uitgevoerd door de platformoperator, doorgaans de gebruiker, wanneer deze fysiek aanwezig is op het platform. Dit vereist dat de command-methode beperkt is tot alleen beschikbaar terwijl de platformstatus deze zekerheid kan bieden. Deze status bestaat meestal tijdens de boot naar UEFI-installatie voorafgaand aan de beschikbaarheid van een netwerkstack en blootstelling aan potentieel niet-vertrouwde software.