mboost-dp1
unknown
#2:
Hehe, det tror jeg roligt du kan sige ;)
DRM = Digital Rights Management.
Relaterede emner (til Google):
Palladium
Fritz-chip
TCG (Trusted Computing Group)
TCPA
NGSCB
Emner som ALTID kommer op i Newz når ovennævnte emner blot svagt berøres:
APG
RIAA
P2P
Microsoft vs Linux (hæhæ - det gælder for 99.5% af alle emner) ;)
Hehe, det tror jeg roligt du kan sige ;)
DRM = Digital Rights Management.
Relaterede emner (til Google):
Palladium
Fritz-chip
TCG (Trusted Computing Group)
TCPA
NGSCB
Emner som ALTID kommer op i Newz når ovennævnte emner blot svagt berøres:
APG
RIAA
P2P
Microsoft vs Linux (hæhæ - det gælder for 99.5% af alle emner) ;)
#4
Det kan godt være at DRM første gang blev benyttet i sammenhæng med at hardware skulle beskytte software.
Men nu bruges DRM i flæng med alt der på nogen måde kan forhindre ophavsretbrud. Dvs ting som vandmærkning, fingeraftryk (genkendelse af kontekst), softwarebeskyttelse og ID på produkter.
Artiklen kommer således ikke en eneste gang ind på NGSCB eller TCPA.
Den nævner dog Microsofts RMS, og dette er stadig kun en softwareløsning.
(Du har dog ret i de flamewars der bliver startet af emnet ;)
Det kan godt være at DRM første gang blev benyttet i sammenhæng med at hardware skulle beskytte software.
Men nu bruges DRM i flæng med alt der på nogen måde kan forhindre ophavsretbrud. Dvs ting som vandmærkning, fingeraftryk (genkendelse af kontekst), softwarebeskyttelse og ID på produkter.
Artiklen kommer således ikke en eneste gang ind på NGSCB eller TCPA.
Den nævner dog Microsofts RMS, og dette er stadig kun en softwareløsning.
(Du har dog ret i de flamewars der bliver startet af emnet ;)
#3 nej DRM har ikke nødvendigvis noget med hardwaren at gøre.
Jeg synes DRM har en masse goder, men jeg tror nogle går for vidt, med fx DRM på film og mp3'er, som dog er blevet bedre siden de har givet det lov til at komme ned på afspillere. Og fx Palladium.
Dog synes jeg den har en masse andre goder som, intern firma sikkerhed, for at opretholde NDA'er m.m.
Jeg synes DRM har en masse goder, men jeg tror nogle går for vidt, med fx DRM på film og mp3'er, som dog er blevet bedre siden de har givet det lov til at komme ned på afspillere. Og fx Palladium.
Dog synes jeg den har en masse andre goder som, intern firma sikkerhed, for at opretholde NDA'er m.m.
Den største fordel ved DRM er at det per definition er defekt. Det kan ikke lade sig gøre at implementere DRM i open source software. Min holdning er at hvis sikkerheden ligger i at nægte folk adgang til kildekoden, så er der ikke meget sikkerhed tilbage. Jeg tror de fleste crypto folk vil give mig ret.
Til de der ikke kan se hvorfor det ikke vil virke:
Hvis vi f.eks tager DRM beskyttet musik, så er det selve afspilleren der skal styre rettighederne. Hvis jeg har kildekoden kan jeg relativt nemt få afspilleren til at ignorere de rettigheder. Det kan man fordi musik, film, tekst, billeder og alle andre informationer, der på et eller andet tidspunkt skal være tilgængelige for mennesker, på et eller andet tidspunkt må være i decrypteret form. Ved musik er det bare et spørgsmål om at dumpe output til en fil, fremfor lydkortet.
Nå sikkerheden ligger i koden og ikke i metoden er det blot et spørgsmål mon tid. DRM og især Microsoft IRM (Information Rights Management) er ikke andet end falsk trykhed.
Til de der ikke kan se hvorfor det ikke vil virke:
Hvis vi f.eks tager DRM beskyttet musik, så er det selve afspilleren der skal styre rettighederne. Hvis jeg har kildekoden kan jeg relativt nemt få afspilleren til at ignorere de rettigheder. Det kan man fordi musik, film, tekst, billeder og alle andre informationer, der på et eller andet tidspunkt skal være tilgængelige for mennesker, på et eller andet tidspunkt må være i decrypteret form. Ved musik er det bare et spørgsmål om at dumpe output til en fil, fremfor lydkortet.
Nå sikkerheden ligger i koden og ikke i metoden er det blot et spørgsmål mon tid. DRM og især Microsoft IRM (Information Rights Management) er ikke andet end falsk trykhed.
#11 Nu handler det jo ikke kun om selve computeren, men også softwaren, musik og film. På musik området er det allerede sket. Det musik folk køber f.eks gennem iTunes eller diverse On2 sites (TDC Musikshop). Kunderne har ikke meget kontrol over de numre de køber, pladeselskaberne kan til en hver tid ændre rettighederne.
Bitter Hva'
Bitter Hva'
#7
Nej, DRM har ikke noget med Open Source at gøre.
Du kan sagtens have alle programmerne i Open Source, og så bruge en nøgle til at underskrive programmerne med.
Herefter kan man kun benytte programmet til de opgaver, som man har rettigheder til.
TCPA har længe været understøttet af f.eks Linux, hvis man vil have et ekstra sikkerhedslag før at ansatte kan stjæle dokumenter.
Problemet er at hver gang man oversætter en ny kerne, skal man underskrive den.
Dette giver selv sagt problemer, da mange hobby folk selv oversætter deres kerne, og det er kun musik/film/software industrien (læs Microsoft) som kan underskrive den.
Men hvis man bruger DRM i virksomheden er der intet galt i at bruge Open Source.
Nej, DRM har ikke noget med Open Source at gøre.
Du kan sagtens have alle programmerne i Open Source, og så bruge en nøgle til at underskrive programmerne med.
Herefter kan man kun benytte programmet til de opgaver, som man har rettigheder til.
TCPA har længe været understøttet af f.eks Linux, hvis man vil have et ekstra sikkerhedslag før at ansatte kan stjæle dokumenter.
Problemet er at hver gang man oversætter en ny kerne, skal man underskrive den.
Dette giver selv sagt problemer, da mange hobby folk selv oversætter deres kerne, og det er kun musik/film/software industrien (læs Microsoft) som kan underskrive den.
Men hvis man bruger DRM i virksomheden er der intet galt i at bruge Open Source.
#13 Hvis jeg husker rigtigt er TCPA implementeret i hardware.
Jeg tror ikke helt du har forstået hvad problemet er. Når folk har adgang til kildekoden kan de ændre hvad der skal ske med det dekodede materialle og så er DRM ikke meget værd. DRM i f.eks Windows Media Player virker ved at playeren bliver orienteret om hvilke rettigheder der er forbundet med en fil og sikre at brugere ikke kan gøre noget der ligger ud over de rettigheder. Havde man adgang til koden kunne man bare bede Media Player om at dekryptere filen og gemme en ukrypteret kopi. I open source hvor man jo altid kan pille ved kode er der ikke noget der forhindre folk i at dumpe det dekrypterede materialle til en fil.
Det du nævner er en helt anden problemstilling hvor selve computer hardwaren kræver at software har en gyldig signatur, hvilket ville være katastrofalt for open source samfundet.
Der er ikke noget galt i at DRM og open source spiller sammen... det kan bare ikke lade sig gøre. Jeg har i hvertfald ikke kunne regne ud hvordan det ville virke.
Jeg tror ikke helt du har forstået hvad problemet er. Når folk har adgang til kildekoden kan de ændre hvad der skal ske med det dekodede materialle og så er DRM ikke meget værd. DRM i f.eks Windows Media Player virker ved at playeren bliver orienteret om hvilke rettigheder der er forbundet med en fil og sikre at brugere ikke kan gøre noget der ligger ud over de rettigheder. Havde man adgang til koden kunne man bare bede Media Player om at dekryptere filen og gemme en ukrypteret kopi. I open source hvor man jo altid kan pille ved kode er der ikke noget der forhindre folk i at dumpe det dekrypterede materialle til en fil.
Det du nævner er en helt anden problemstilling hvor selve computer hardwaren kræver at software har en gyldig signatur, hvilket ville være katastrofalt for open source samfundet.
Der er ikke noget galt i at DRM og open source spiller sammen... det kan bare ikke lade sig gøre. Jeg har i hvertfald ikke kunne regne ud hvordan det ville virke.
#4 TCPA er ikke et DRM system i den forstand man normalt bruger når man taler DRM, TCPA er et system til at kontrolere hvem og hvad der kan instaleres på en bestemt computer.
TCPA tjækker om det software man vil afvikle på en computer er certificeret korekt, og fungere som en slags nøglering.
Ifølge de oprindelige TCPA-specifikationer vil ejeren af en computer have fuld kontrol over signerings proceduren, der hvor prblemet opstår er med paladium/NGSCB hvor MS vil have at man overlader denne kontrol til en form for myndighed.
TCPA-chippen er en slags udvidet BIOS, og der er egentligt ikke noget i vejen for at TCPA-chippen kan spille perfekt sammen med OpenSource.
Problemet opstår først hvis brugeren mister retten til frit at vælge software som Pladium ligger op til.
TCPA tjækker om det software man vil afvikle på en computer er certificeret korekt, og fungere som en slags nøglering.
Ifølge de oprindelige TCPA-specifikationer vil ejeren af en computer have fuld kontrol over signerings proceduren, der hvor prblemet opstår er med paladium/NGSCB hvor MS vil have at man overlader denne kontrol til en form for myndighed.
TCPA-chippen er en slags udvidet BIOS, og der er egentligt ikke noget i vejen for at TCPA-chippen kan spille perfekt sammen med OpenSource.
Problemet opstår først hvis brugeren mister retten til frit at vælge software som Pladium ligger op til.
#15
Jeg synes også at DRM forbrugermæssigt skal væk. IMO skal det være et certifikat system. Hvor firmaer kan ansøge om et certifikat til internt brug.
Egentlig det eneste sted jeg ser DRM som en fordel.
Kan ikke se hvad en forbruger skal bruge låste dokumenter, m.m. til.
Dog kan jeg godt se en fordel for koncerner der ikke vil have sine interne notater lækket.
Jeg synes også at DRM forbrugermæssigt skal væk. IMO skal det være et certifikat system. Hvor firmaer kan ansøge om et certifikat til internt brug.
Egentlig det eneste sted jeg ser DRM som en fordel.
Kan ikke se hvad en forbruger skal bruge låste dokumenter, m.m. til.
Dog kan jeg godt se en fordel for koncerner der ikke vil have sine interne notater lækket.
#14,
Jeg mener du har fat i det rigtige,
TCPA er, så vidt jeg har forstået, et sammenspil mellem noget hardware og software.
Når computeren starterop, checkes hardwaren og en del at styresystem. Hvis hardware delen siger ok for hardwaren, og sytresystem ikke er ændret, starter den styresystem op.
Det er nu op til styresystem at sikre at der ikke er nogen, der gør noget, de ikke må.
Hardwaren delen virker herefter også som et nøgle/krypterings enhed, som styresystemet kan benytte sig af.
Der er sådan set ikke noget i vejen for at OpenSource kan bruge TCPA. Men når f.eks. en kerne er blevet kompileret skal en eller anden underskrive den, dvs. sige god for at den ikke tillader nogen at gøre noget de ikke må (Det kunne f.eks. være at brugeren ikke skal kunne læse et vilkårligt sted i RAM, eller indlæse en eller anden driver.
Hvis man ville afspille et stykke musik med DRM, skulle man bruge en player som også var underskrevet (altså godkendt, dvs. en eller anden siger god for at den kompileret sourcekode f.eks. ikke tillader at man gemmer det afspillet musik på HD)
Problemet er så bare at dem der udgiver musikken, kun vil give dig udkrypterings nøglen, hvis du kører med en undskrevet afspiller, som kører på et underskrevet styresystem.
Problemet for OpenSource er at det sandsynligvis vil koste en del penge at få f.eks. en kerne underskrevet, fordi en eller anden skal gå hele source koden igennem, og sikre at der ikke er en eller anden bagdør, som gør at man f.eks. kan læse fra et vilkårligt sted i RAM.
(Samme problem med den OpenSource player man skal bruge)
Hvis man vil bruge det i f.eks. et firma er det noget nemmere. Så kan man jo selv underskrive kernen og de programmer man skal bruge.
Jeg håber det var til at forstå, ellers så stil endeligt spg.
Jeg mener du har fat i det rigtige,
TCPA er, så vidt jeg har forstået, et sammenspil mellem noget hardware og software.
Når computeren starterop, checkes hardwaren og en del at styresystem. Hvis hardware delen siger ok for hardwaren, og sytresystem ikke er ændret, starter den styresystem op.
Det er nu op til styresystem at sikre at der ikke er nogen, der gør noget, de ikke må.
Hardwaren delen virker herefter også som et nøgle/krypterings enhed, som styresystemet kan benytte sig af.
Der er sådan set ikke noget i vejen for at OpenSource kan bruge TCPA. Men når f.eks. en kerne er blevet kompileret skal en eller anden underskrive den, dvs. sige god for at den ikke tillader nogen at gøre noget de ikke må (Det kunne f.eks. være at brugeren ikke skal kunne læse et vilkårligt sted i RAM, eller indlæse en eller anden driver.
Hvis man ville afspille et stykke musik med DRM, skulle man bruge en player som også var underskrevet (altså godkendt, dvs. en eller anden siger god for at den kompileret sourcekode f.eks. ikke tillader at man gemmer det afspillet musik på HD)
Problemet er så bare at dem der udgiver musikken, kun vil give dig udkrypterings nøglen, hvis du kører med en undskrevet afspiller, som kører på et underskrevet styresystem.
Problemet for OpenSource er at det sandsynligvis vil koste en del penge at få f.eks. en kerne underskrevet, fordi en eller anden skal gå hele source koden igennem, og sikre at der ikke er en eller anden bagdør, som gør at man f.eks. kan læse fra et vilkårligt sted i RAM.
(Samme problem med den OpenSource player man skal bruge)
Hvis man vil bruge det i f.eks. et firma er det noget nemmere. Så kan man jo selv underskrive kernen og de programmer man skal bruge.
Jeg håber det var til at forstå, ellers så stil endeligt spg.
#20 er TCPA == DRM i alle situationer?
Gider i ikke lige prøve at finde ud af hvad forskellen på TCPA og paladium/NGSCB/DRM egentligt er.
Linux er faktisk PT det eneste OS på markedet for desktop operativ systemer der kan bruge TCPA-chippen til noget som helts fornuftigt, og det er med hjemmekompileret GPL kode.
Så længe man ikke skal autorisere op mod en central server er TCPA ikke et problem, og hvis man skal autorisere op mod en central server er TCPA ikke nødvendig for at skabe alhvorlige problemer.
Gider i ikke lige prøve at finde ud af hvad forskellen på TCPA og paladium/NGSCB/DRM egentligt er.
Linux er faktisk PT det eneste OS på markedet for desktop operativ systemer der kan bruge TCPA-chippen til noget som helts fornuftigt, og det er med hjemmekompileret GPL kode.
Så længe man ikke skal autorisere op mod en central server er TCPA ikke et problem, og hvis man skal autorisere op mod en central server er TCPA ikke nødvendig for at skabe alhvorlige problemer.
Lad os lige slå fast, at teknikken bag DRM kan bruges til fornuftige ting.
Men så hedder det altså ikke længere DRM.
TCPA kan mange for os forbrugere nyttige ting.
DRM er bare den grimme bismag.
Og det er sjovt nok DRM delen, der er grunden til at der er kræfter der er så ivrige efter at få det tvangsimplementeret i ALT hardware.
Men så hedder det altså ikke længere DRM.
TCPA kan mange for os forbrugere nyttige ting.
DRM er bare den grimme bismag.
Og det er sjovt nok DRM delen, der er grunden til at der er kræfter der er så ivrige efter at få det tvangsimplementeret i ALT hardware.
Der er helt tydelig mange misforståelser om hvad TCPA og NGSCB er. Jeg har sat mig grundigt ind i disse teknologier i forbindelse med mit arbejde og den korte historie er følgende:
TCPA: TCPA er en alliance af computefirmaer der har udviklet specifikationerne til en chip, som kaldes en TPM (Trusted Platform Module). Man kan allerede nu købe computere (fx IBM Thinkpads) med en TPM og Intel har et bundkort i sit sortiment med en TPM på. TPM'en fungerer som et "key storage" hvori brugerne kan genererer deres nøgler og herefter signere og kryptere data med disse nøgler. Idéen er at selve nøglen ikke forlader chippen. Hvis softwaren skal bruge nøglen kan chippen selv signe/kryptere og spytte resultatet ud. Men selve nøglen kan ikke komme ud. På den måde kan en indtrængende virus der kommer ind ikke kopiere nøglen og sende den til sin ophavsmand. Virusen kan allerhøjst misbruge nøglen mens den er på computeren. TPM'erne man i dag kan få følger version 1.1 af standarden. Der er lidt ekstra funktioner i TPM'en men den er i grunden ikke ret avanceret. Det hele kan bruges i Linux.
På grund af intern uenighed udbrød en gruppe fra TCPA af alliancen og dannede TCG (Trusted Computing Group). De har lavet version 1.2 af standarden som kan få langt større betydning - se nedenfor.
NGSCB: Next Generation Secure Computing Base er et initiativ fra Microsoft som stiler mod at koble en række sikkerhedsteknologier i hardware sammen. NGSCB er ikke som sådan en DRM-teknologi men den tilbyder nogle primitiver der kan bruges til mange ting - heriblandt DRM.
NGSCB griber meget vidt om sig. Udover at computeren skal udstyres med en TPM version 1.2 chip skal også CPU, chipset og grafikkort udsættes for mindre ændringer for at opnå den højeste sikkerhed.
Intel og AMD arbejder begge med udvidelser til CPU og chipset. Intels system går under kodenavnet LaGrande og AMD's system går under navnet SEM. De to systemer er inkompatible men Microsoft's NGSCB vil understøtte begge teknologier. NVidia og ATI har annonceret, at de vil være klar med grafikkort med sikkerhedsteknologi når Microsoft's næste version af Windows ("Longhorn") står klar, forventligt om 1½ år. Lige nu er der beta-version er Longhorn ude, der emulerer sikkerhedshardwaren, som altså ikke er på markedet endnu.
Detaljerne i hvordan NGSCB fungerer ville tage lang tid at beskrive. Men kort fortalt giver NGSCB programmer mulighed for at beskytte deres hukommelse 100% - selv overfor systemprogrammer (Windows, drivere o.s.v.). Beskyttelsen foregår ved at CPU'en får en ny tilstand (kaldet TX på AMD, ved ikke hvad navnet er på Intel) hvori der indlæses en mini-operativsystem kerne (en Nexus i NGSCB-terminologi). Denne Nexus indlæses efter at hele operativsystemet er startet op i den normale tilstand. Nexus'en får tildelt et område af hukommelsen som den ejer 100%. Ikke engang Windows og drivere m.m. kan få adgang - selv busmasters kan ikke tilgå det via DMA. Nexusen kan så starte programmer op, som er skrevet af "almindelige" udviklere. Nexusen kan give kryptografiske beviser for at et program er det som det udgiver sig for. Nexus'en er iøvrigt i stand til at bevise dens egen identitet takket være teknologier i TPM'en. Dette kan ske på en måde som ikke kan emuleres på en ikke-NGSCB maskine.
En anvendelse af teknologien er fx netspil hvor en spil-server vil kunne få et bevis for at spilleren kører en umodificeret udgave af klienten, for at undgå snyd.
NGSCB lægger meget vægt på at brugeren anonymitet beskyttes 100% og at brugeren har helt styr på hvad han/hun kører på computeren. Der er ingen der tager kontrollen med den enkeltes computer. Ydermere vil ens gamle programmer fortsætte med at kunnekøre. Man kan således fortsætte med at køre sine mod'ede klienter, men hvis en server kræver bevis for at man kører en ikke-mod'ed klient kan man vælge ikke at give beviset (og dermed ikke få lov til at spille) eller at give beviset så serveren kan se klienten er umodificeret (og nægte hvis den er modificeret).
Med NGSCB beskyttes de enkelte programmer på maskinen mod hinanden, sådan at Word fx ikke kan få adgang til netbankens crypto-nøgler o.s.v. Desuden laves systemer så programmer ikke kan se hvad hinanden skriver på skærmen, og teknologier så brugeren kan være sikker på at det han/hun indtaster på keyboardet nu også kun kan ses at det program han/hun har aktivt på skærmen, og for i det hele taget at kunne få bevis for det aktive programs identitet (det kunne jo være et fup-program der bare "ligner", rent grafisk).
NGSCB kan bruges til rigtig meget - herunder DRM. I første omgang henvender teknologien sig til erhvervslivet, men Microsoft har erklæret at teknologien skal anvendes til spil og DRM. Der er dog ikke noget "farligt" ved at have en NGSCB-maskine for de programmer der vil udnytte NGSCB til DRM vil nægte at køre på en ikke-DRM maskine. En måde dette kan fungerer på kunne være, at man når man køber programmet ikke får det hele med. Resten skal downloades til det beskyttede miljø fra en server - som selvfølgelig kun går med til det, når den har verificeret at computeren understøtter NGSCB.
DRM-beskyttelse af video og lyd er langt sværere idet dette på et eller andet tidspunkt skal konverteres til analogt, hvilket gør det langt sværere at kontrollere.
TCPA: TCPA er en alliance af computefirmaer der har udviklet specifikationerne til en chip, som kaldes en TPM (Trusted Platform Module). Man kan allerede nu købe computere (fx IBM Thinkpads) med en TPM og Intel har et bundkort i sit sortiment med en TPM på. TPM'en fungerer som et "key storage" hvori brugerne kan genererer deres nøgler og herefter signere og kryptere data med disse nøgler. Idéen er at selve nøglen ikke forlader chippen. Hvis softwaren skal bruge nøglen kan chippen selv signe/kryptere og spytte resultatet ud. Men selve nøglen kan ikke komme ud. På den måde kan en indtrængende virus der kommer ind ikke kopiere nøglen og sende den til sin ophavsmand. Virusen kan allerhøjst misbruge nøglen mens den er på computeren. TPM'erne man i dag kan få følger version 1.1 af standarden. Der er lidt ekstra funktioner i TPM'en men den er i grunden ikke ret avanceret. Det hele kan bruges i Linux.
På grund af intern uenighed udbrød en gruppe fra TCPA af alliancen og dannede TCG (Trusted Computing Group). De har lavet version 1.2 af standarden som kan få langt større betydning - se nedenfor.
NGSCB: Next Generation Secure Computing Base er et initiativ fra Microsoft som stiler mod at koble en række sikkerhedsteknologier i hardware sammen. NGSCB er ikke som sådan en DRM-teknologi men den tilbyder nogle primitiver der kan bruges til mange ting - heriblandt DRM.
NGSCB griber meget vidt om sig. Udover at computeren skal udstyres med en TPM version 1.2 chip skal også CPU, chipset og grafikkort udsættes for mindre ændringer for at opnå den højeste sikkerhed.
Intel og AMD arbejder begge med udvidelser til CPU og chipset. Intels system går under kodenavnet LaGrande og AMD's system går under navnet SEM. De to systemer er inkompatible men Microsoft's NGSCB vil understøtte begge teknologier. NVidia og ATI har annonceret, at de vil være klar med grafikkort med sikkerhedsteknologi når Microsoft's næste version af Windows ("Longhorn") står klar, forventligt om 1½ år. Lige nu er der beta-version er Longhorn ude, der emulerer sikkerhedshardwaren, som altså ikke er på markedet endnu.
Detaljerne i hvordan NGSCB fungerer ville tage lang tid at beskrive. Men kort fortalt giver NGSCB programmer mulighed for at beskytte deres hukommelse 100% - selv overfor systemprogrammer (Windows, drivere o.s.v.). Beskyttelsen foregår ved at CPU'en får en ny tilstand (kaldet TX på AMD, ved ikke hvad navnet er på Intel) hvori der indlæses en mini-operativsystem kerne (en Nexus i NGSCB-terminologi). Denne Nexus indlæses efter at hele operativsystemet er startet op i den normale tilstand. Nexus'en får tildelt et område af hukommelsen som den ejer 100%. Ikke engang Windows og drivere m.m. kan få adgang - selv busmasters kan ikke tilgå det via DMA. Nexusen kan så starte programmer op, som er skrevet af "almindelige" udviklere. Nexusen kan give kryptografiske beviser for at et program er det som det udgiver sig for. Nexus'en er iøvrigt i stand til at bevise dens egen identitet takket være teknologier i TPM'en. Dette kan ske på en måde som ikke kan emuleres på en ikke-NGSCB maskine.
En anvendelse af teknologien er fx netspil hvor en spil-server vil kunne få et bevis for at spilleren kører en umodificeret udgave af klienten, for at undgå snyd.
NGSCB lægger meget vægt på at brugeren anonymitet beskyttes 100% og at brugeren har helt styr på hvad han/hun kører på computeren. Der er ingen der tager kontrollen med den enkeltes computer. Ydermere vil ens gamle programmer fortsætte med at kunnekøre. Man kan således fortsætte med at køre sine mod'ede klienter, men hvis en server kræver bevis for at man kører en ikke-mod'ed klient kan man vælge ikke at give beviset (og dermed ikke få lov til at spille) eller at give beviset så serveren kan se klienten er umodificeret (og nægte hvis den er modificeret).
Med NGSCB beskyttes de enkelte programmer på maskinen mod hinanden, sådan at Word fx ikke kan få adgang til netbankens crypto-nøgler o.s.v. Desuden laves systemer så programmer ikke kan se hvad hinanden skriver på skærmen, og teknologier så brugeren kan være sikker på at det han/hun indtaster på keyboardet nu også kun kan ses at det program han/hun har aktivt på skærmen, og for i det hele taget at kunne få bevis for det aktive programs identitet (det kunne jo være et fup-program der bare "ligner", rent grafisk).
NGSCB kan bruges til rigtig meget - herunder DRM. I første omgang henvender teknologien sig til erhvervslivet, men Microsoft har erklæret at teknologien skal anvendes til spil og DRM. Der er dog ikke noget "farligt" ved at have en NGSCB-maskine for de programmer der vil udnytte NGSCB til DRM vil nægte at køre på en ikke-DRM maskine. En måde dette kan fungerer på kunne være, at man når man køber programmet ikke får det hele med. Resten skal downloades til det beskyttede miljø fra en server - som selvfølgelig kun går med til det, når den har verificeret at computeren understøtter NGSCB.
DRM-beskyttelse af video og lyd er langt sværere idet dette på et eller andet tidspunkt skal konverteres til analogt, hvilket gør det langt sværere at kontrollere.
#26: Der er p.t. ingen planer om at gøre den almindelige RAM i computeren krypteret. Det vil være ganske almindelige RAM. Andet ville være for langsomt. Det er derfor i princippet muligt at få adgang til RAM'en ved at sætte ledninger direkte på RAM-modulerne. Det er dog ret indviklet i praksis men bestemt ikke umuligt.
Der er dog indbygget beskyttelse af de områder videokortets framebuffer der bruges at beskyttede programmer. TPM'en har noget storage der er beskyttet af hardware.
Ifølge specifikationerne behøver platformen som helhed dog ikke kunne modstå "avancerede hardwareangreb". Hvis man krævede dette ville det blive for dyrt. Jeg har set beregninger der viser, at al den nye hardware højst vil lægge $20 til en PC's pris.
Arkitekturen bliver ikke 100% sikker mod hardwareangreb. Det primære formål er at forhindre softwareangreb (fx fra en virus, som ikke kan sætte ledninger fast på RAM'en o.s.v.!). I DRM-sammenhæng, hvor man ikke stoler på brugeren, skal man også overveje hardwareangreb, men her har man valgt at sætte grænsen ved "avancerede hardwareangreb". Jeg tror firmaernes tankegang er, at hvis det kræver bare et mindre hardware-indgreb at bryde systemet, vil det gevaldigt nedsætte mængden af piratkopiering. Det er trods alt de færreste der gider skulle gå igennem alt bøvlet med aflytning af RAM'en. På den anden side skal bare en gør det for at alle kan få fat i det kopierede.
Hvis det skulle lykkedes nogen at få nøgler og certifikater ud af TPM'en, kunne man i princippet lave en NGSCB-emulator der ville se ud som en ægte NGSCB-platform. Dette kunne så bruges til at snyde i netspil. Dog ville være enkelt bruger være nødt til at bryde sin egen maskine, idet det ville være let at opdage hvis de samme TPM-nøgler blev brugt af mange brugere. Når dette opdages, kan TPM'en komme på en liste over TPM'er der ikke stoles på uden at det påvirker andre brugere.
I hvert fald i version 1.2 af standarden er der taget højde for at det før eller siden vil lykkes for nogen at få adgang til TPM'ens nøgler og det beskrives hvordan man i denne situation forhindrer misbrug.
Se mere her:
https://www.trustedcomputinggroup.org/ (hjemmeside for de der udviklet TPM'en - her kan specsene til TPM'en hentes).
http://www.microsoft.com/whdc/winhec/pres03.mspx (Under kategorien "System design and innovation", Trusted Platform Technologies, findes et hav af præsentationer om sikkerhedsteknologien).
http://www.microsoft.com/whdc/winhec/papers03.mspx (her findes en del papers om al mulig fremtidig hardware - særligt interessant er AMD's paper om sikkerhedssystemerne som vil komme med i deres fremtidige CPU'er og chipsæt).
http://www.microsoft.com/resources/ngscb/default.m... (Microsoft generelle side om NGSCB).
Have fun :)
Der er dog indbygget beskyttelse af de områder videokortets framebuffer der bruges at beskyttede programmer. TPM'en har noget storage der er beskyttet af hardware.
Ifølge specifikationerne behøver platformen som helhed dog ikke kunne modstå "avancerede hardwareangreb". Hvis man krævede dette ville det blive for dyrt. Jeg har set beregninger der viser, at al den nye hardware højst vil lægge $20 til en PC's pris.
Arkitekturen bliver ikke 100% sikker mod hardwareangreb. Det primære formål er at forhindre softwareangreb (fx fra en virus, som ikke kan sætte ledninger fast på RAM'en o.s.v.!). I DRM-sammenhæng, hvor man ikke stoler på brugeren, skal man også overveje hardwareangreb, men her har man valgt at sætte grænsen ved "avancerede hardwareangreb". Jeg tror firmaernes tankegang er, at hvis det kræver bare et mindre hardware-indgreb at bryde systemet, vil det gevaldigt nedsætte mængden af piratkopiering. Det er trods alt de færreste der gider skulle gå igennem alt bøvlet med aflytning af RAM'en. På den anden side skal bare en gør det for at alle kan få fat i det kopierede.
Hvis det skulle lykkedes nogen at få nøgler og certifikater ud af TPM'en, kunne man i princippet lave en NGSCB-emulator der ville se ud som en ægte NGSCB-platform. Dette kunne så bruges til at snyde i netspil. Dog ville være enkelt bruger være nødt til at bryde sin egen maskine, idet det ville være let at opdage hvis de samme TPM-nøgler blev brugt af mange brugere. Når dette opdages, kan TPM'en komme på en liste over TPM'er der ikke stoles på uden at det påvirker andre brugere.
I hvert fald i version 1.2 af standarden er der taget højde for at det før eller siden vil lykkes for nogen at få adgang til TPM'ens nøgler og det beskrives hvordan man i denne situation forhindrer misbrug.
Se mere her:
https://www.trustedcomputinggroup.org/ (hjemmeside for de der udviklet TPM'en - her kan specsene til TPM'en hentes).
http://www.microsoft.com/whdc/winhec/pres03.mspx (Under kategorien "System design and innovation", Trusted Platform Technologies, findes et hav af præsentationer om sikkerhedsteknologien).
http://www.microsoft.com/whdc/winhec/papers03.mspx (her findes en del papers om al mulig fremtidig hardware - særligt interessant er AMD's paper om sikkerhedssystemerne som vil komme med i deres fremtidige CPU'er og chipsæt).
http://www.microsoft.com/resources/ngscb/default.m... (Microsoft generelle side om NGSCB).
Have fun :)
#25 og #27
Du har mange rigtige pointer i, og jeg er ikke i tvivl om at du har sat der ind i sagerne.
Men jeg kunne godt tænke mig hvis du gjorde det mere klart, hvilke egenskaber der kan integreres i software.
F. eks er det ligegyldigt at have en hardware implementering for at opnå følgende:
' Med NGSCB beskyttes de enkelte programmer på maskinen mod hinanden, sådan at Word fx ikke kan få adgang til netbankens crypto-nøgler o.s.v. Desuden laves systemer så programmer ikke kan se hvad hinanden skriver på skærmen, og teknologier så brugeren kan være sikker på at det han/hun indtaster på keyboardet nu også kun kan ses at det program han/hun har aktivt på skærmen, og for i det hele taget at kunne få bevis for det aktive programs identitet (det kunne jo være et fup-program der bare "ligner", rent grafisk).'
Det kan allerede opnås med nuværende CPU arkitektur (dvs uden at programmerne kører emuleret).
Du har helt ret i din antagelse med hensyn til spil, at det kan hjælpe imod snyd. Men herefter skriver du at NGSCB også kan bruges til DRM.
Her er det vigtigt at pointere at det ikke hjælper mod musik, film eller software hvor brugeren ikke har brug for at kontakte en central server.
I forvejen bliver der udgivet unikke nøgler til de fleste multiplayer spil, og ved at tillade at man kun kan spille én nøgle ad gangen forhindrer man effektivt piratkopiering her.
Så det eneste sted at der er en praktisk anvendelse af NGSCB er inden for firmaets fire vægge.
Du har heller ikke nævnt at det er umuligt at designe systemet uden at Microsoft (eller hvem der nu signer kernen...) har ubesværet adgang til din computer.
Dette er selvfølgelig ikke et problem i praksis, da det vil blive et ramaskrig hvis MS pludselig roder i folks private oplysninger - men det _skal_ nævnes.
Så for at opsummere.
I piratkopieringssammenhænge er der _ingen_ forskel, bortset inden for firmavægge.
I snyd inden for spil, kan det have utrolig stor betydning.
Microsoft kan få adgang til din computer.
Personligt synes jeg ikke fordelen ved at folk ikke snyder i spil, er en stor nok fordel til at det skal implementeres.
Og selvfølgelig nævner du ikke Open Source, som selvfølgelig heller ikke er kompatibel med NGSCB.
Du glemte forresten at linke til denne side:
http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html
som du uden tvivl har læst.
Du har mange rigtige pointer i, og jeg er ikke i tvivl om at du har sat der ind i sagerne.
Men jeg kunne godt tænke mig hvis du gjorde det mere klart, hvilke egenskaber der kan integreres i software.
F. eks er det ligegyldigt at have en hardware implementering for at opnå følgende:
' Med NGSCB beskyttes de enkelte programmer på maskinen mod hinanden, sådan at Word fx ikke kan få adgang til netbankens crypto-nøgler o.s.v. Desuden laves systemer så programmer ikke kan se hvad hinanden skriver på skærmen, og teknologier så brugeren kan være sikker på at det han/hun indtaster på keyboardet nu også kun kan ses at det program han/hun har aktivt på skærmen, og for i det hele taget at kunne få bevis for det aktive programs identitet (det kunne jo være et fup-program der bare "ligner", rent grafisk).'
Det kan allerede opnås med nuværende CPU arkitektur (dvs uden at programmerne kører emuleret).
Du har helt ret i din antagelse med hensyn til spil, at det kan hjælpe imod snyd. Men herefter skriver du at NGSCB også kan bruges til DRM.
Her er det vigtigt at pointere at det ikke hjælper mod musik, film eller software hvor brugeren ikke har brug for at kontakte en central server.
I forvejen bliver der udgivet unikke nøgler til de fleste multiplayer spil, og ved at tillade at man kun kan spille én nøgle ad gangen forhindrer man effektivt piratkopiering her.
Så det eneste sted at der er en praktisk anvendelse af NGSCB er inden for firmaets fire vægge.
Du har heller ikke nævnt at det er umuligt at designe systemet uden at Microsoft (eller hvem der nu signer kernen...) har ubesværet adgang til din computer.
Dette er selvfølgelig ikke et problem i praksis, da det vil blive et ramaskrig hvis MS pludselig roder i folks private oplysninger - men det _skal_ nævnes.
Så for at opsummere.
I piratkopieringssammenhænge er der _ingen_ forskel, bortset inden for firmavægge.
I snyd inden for spil, kan det have utrolig stor betydning.
Microsoft kan få adgang til din computer.
Personligt synes jeg ikke fordelen ved at folk ikke snyder i spil, er en stor nok fordel til at det skal implementeres.
Og selvfølgelig nævner du ikke Open Source, som selvfølgelig heller ikke er kompatibel med NGSCB.
Du glemte forresten at linke til denne side:
http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html
som du uden tvivl har læst.
Jeg mener ikke jeg i mine to indlæg har forholdt mig hverken positivt eller negativt til NGSCB. Meningen med dem var at diskutere det teknologiske aspekt snarere end aspekterne med hensyn til privatlivets fred o.s.v. Men jeg vil gerne svare på dit indlæg, idet du blander nogle ting sammen angående TCPA 1.1 og 1.2, specielt hvad angår open source.
Det er rigtigt, når du skriver, at man med den nuværende CPU-arktiektur kan beskytte programmer mod hinanden. Den del af NGSCB-teknologien kunne faktisk i teorien undværes. Behovet for disse teknologier bunder i såvel praktiske som historiske årsager.
Sagen er nemlig den, at som operativsystemer og CPU'er er bygget op i dag, er der to tilstande: Brugertilstand og systemtilstand (x86 understøtter 4 tilstande men ingen bruger dem og de har ingen betydning i denne sammenhæng). Operativsystemet og drivere kører i systemtilstanden og brugerens programmer i brugertilstanden. Programmer i brugertilstand kan ved hjælp af CPU-faciliteter forhindres i få adgang til det der ligger i systemtilstanden (uden o/s'ets tilladelse) ligesom de forskellige programmer kan have seperate adresserum og ikke se hinanden.
Men hvorfor lader man så ikke bare operativsystemet være den komponent som attestere at et program har en bestemt identitet?
Hvis du har fulgt med fra TCPA's begyndelse, så var dette også idéen i starten og det er det som specifikation 1.1 lægger op til. Men en masse praktiske hensyn - heriblandt hensyn til open source - gjorde det umuligt.
Den måde man dengang tænkte sig det skulle virke på var, at der skulle bygges en "chain-of-trust" sådan at den første kode der udføres når computeren tændes ligger i en beskyttet ROM. Denne indlæser så operativsystemet fra disken og laver en hash af den. Operativsystemet laver så en hash af programmer og drivere der indlæses og lægger dem ind i TPM'en. TPM'en kan på forlangende returnere signerede versioner af hash'ene. Idéen er at stoler man på ROM'en+TPM'en (og sidstnævnte har indbyggede, kryptografiske certifikater) så kan man også stole på den første hash. Hvis man så stoler på det operativsystem der har denne hash, så kan man også stole på de hashes det operativsystem laver o.s.v. Teoretisk set kunne dette system godt fungere.
Men hvad så når brugeren opgraderer til en ny grafikkortdriver? En ny musedriver? Eller laver en hjemmekompileret udgave af sin Linux-kerne (ja, NGSCB er egnet til Linux)? Så ændrer hash'ene sig. Derfor ville det kræve at et firma der udbyder software på nettet, og som gerne vil kunne stole på dem der henter det, har en gigantisk database over hash'ene de stoler på. I open-source sammenhæng ville det være helt umuligt idet brugerens egne modifikationer til fx kernen ville give en helt unik kerne som ingen altså vil stole.
En anden ting er også, at ovenstående system kun virker når man stoler på HELE operativsystemet. D.v.s. kerne, filsystemdrivere, diskdrivere, skærmdrivere o.s.v. Alle disse drivere har adgang til ALT - mange megabytes binær kode der altsammen kører i systemtilstand. Hvis blot en enkelt driver er ondsindet, kan den overtage hele computeren (ja, en driver har ligeså meget magt som selve kernen). Den vil derfor også kunne oplyse forkerte attesteringer af de kørende programmer. Selvom man som nævnt ovenfor kan verificere komponenternes identiter (og dermed driverne, hvilket giver en sikker imod ondsindede drivere) er det stadig et problem at skulle stole på SÅ meget. For sandsynligheden for at der er en buffer-overrun fejl i bare en enkelt driver er altså ret stor.
Ved Intel's Lagrande og AMD's SEM, tilføjes en ny mode hvor der indlæses en meget lille kerne. Denne kerne indlæses på en sikker måde og den er alt hvad du behøver at stole på. Denne kerne er lille nok til at den kan offentliggøres og analyseres ved formelle metoder.
Selvfølgelig kan programmer i den nye sikre tilstand få brug for diskplads o.s.v. og adgangen hertil foregår ved at der sker et kald til de "gamle" drivere inde fra den sikre tilstand. Programmerne i den sikre tilstand skal blot kryptere deres data inden disse gives til de "usikre diskdrivere". Diskdriverne i systemet kan altså højst nægte programmerne i den sikre tilstand funktionalitet, men de kan ikke få adgang til fortrolige oplysninger. Samme princip anvendes ved brug af keyboard, mus og skærm idet der forinden etableres end end-to-end krypteret forbindelse til disse enheder - men selve den krypterede kommunikation foregår gennem de almindelige drivere (som man ikke stoler på).
Da den kerne vi snakker om er så lille som den er, behøver den heller ikke at ændre sig særlig ofte. Open-source miljøet kan derfor også selv lave en sådan mini-kerne / Nexus. Hvis brugeren ændrer i den er der ganske vist ingen der stoler på den, men da den er så lille og begrænset i funktionalitet vil der ikke være noget reelt behov for at ændre i den. Man kan fortsat lave alle de modifikationer man har lyst til til Linux-kernen, det er kun Nexus'en der skal være stabil.
Med hensyn til om film/musik kan beskyttes så behøver folk ikke have netadgang for at lytte til musikken (for at tage det eksempel). De skal blot have det i forbindelse med attesteringen når de downloader den (herefter kommer musikken i NGSCB-agentens kontrol og lagres krypteret på harddisken - og kan herefter frit benyttes at det attesterede program selv når der ikke er netforbindelse).
Forresten så er det noget sludder du skriver at systemet ikke kan designes uden at Microsoft har uhindret adgang. I hvert fald tilfører det ingen ekstra risiko i forhold til i dag - snarere tværtimod! Nexus'ens kode bliver offentlig tilgængelig og er ret lille. Så faktisk er det mere sikkert end i dag hvor du lægger dine data i hænderne på programmer hvis adresserum er tilgængeligt for al Windows system-koden som du ikke kan se hvordan virker. Der kunne sagtens være en bagdør uden at du opdagede det.
Jeg kan heller ikke se hvordan det med at der bruges individuelle nøgler til multiplayerspil i dag betyder at NGSCB ikke kan få betydning for piratkopiering uden for firmaets fire vægge. For det første kan serienumre m.m. omgås (tror du selv at alle kører på lovlige klienter i dag?) og for det andet bruger private også andre programmer end spil.
Det er også en fejlslutning når du siger, at du synes behovet for at sikre mod snyd i spil ikke retfærdiggøre NGSCB. For det med spilsnyd var bare et eksempel på en ikke-ond anvendelse som jeg gav. Der er MANGE andre gode anvendelser af NGSCB. I forbindelse med al P2P er det fx interessant at klienterne kan attestere sig for hinanden sådan at man ikke kan køre med en ond klient der ødelægger netværket. I forbindelse med messenging o.s.v. er det også interessant.
Og angående Ross Andersons FAQ. Ross Anderson er en meget anerkendt kryptoekspert som jeg har stor respekt for. Desværre har han lavet en meget dårlig FAQ om TCPA/NGSCB. Der er helt fundamentale misforståelser med hensyn til hvordan TCPA/NGSCB virker. Det kommer måske delvist af at den blev skrevet på et tidspunkt hvor der ikke var meget info offentlig tilgængeligt. Nu er de VÆRSTE fejlinformationer heldigvis efterhånden taget ud af FAQ'en på grund af artikler der modsagde den oprindelige version punkt for punkt. Men der er stadig ting der er meget misvisende. Det er absolut ikke en troværdig kilde til information om disse teknologier.
Det er rigtigt, når du skriver, at man med den nuværende CPU-arktiektur kan beskytte programmer mod hinanden. Den del af NGSCB-teknologien kunne faktisk i teorien undværes. Behovet for disse teknologier bunder i såvel praktiske som historiske årsager.
Sagen er nemlig den, at som operativsystemer og CPU'er er bygget op i dag, er der to tilstande: Brugertilstand og systemtilstand (x86 understøtter 4 tilstande men ingen bruger dem og de har ingen betydning i denne sammenhæng). Operativsystemet og drivere kører i systemtilstanden og brugerens programmer i brugertilstanden. Programmer i brugertilstand kan ved hjælp af CPU-faciliteter forhindres i få adgang til det der ligger i systemtilstanden (uden o/s'ets tilladelse) ligesom de forskellige programmer kan have seperate adresserum og ikke se hinanden.
Men hvorfor lader man så ikke bare operativsystemet være den komponent som attestere at et program har en bestemt identitet?
Hvis du har fulgt med fra TCPA's begyndelse, så var dette også idéen i starten og det er det som specifikation 1.1 lægger op til. Men en masse praktiske hensyn - heriblandt hensyn til open source - gjorde det umuligt.
Den måde man dengang tænkte sig det skulle virke på var, at der skulle bygges en "chain-of-trust" sådan at den første kode der udføres når computeren tændes ligger i en beskyttet ROM. Denne indlæser så operativsystemet fra disken og laver en hash af den. Operativsystemet laver så en hash af programmer og drivere der indlæses og lægger dem ind i TPM'en. TPM'en kan på forlangende returnere signerede versioner af hash'ene. Idéen er at stoler man på ROM'en+TPM'en (og sidstnævnte har indbyggede, kryptografiske certifikater) så kan man også stole på den første hash. Hvis man så stoler på det operativsystem der har denne hash, så kan man også stole på de hashes det operativsystem laver o.s.v. Teoretisk set kunne dette system godt fungere.
Men hvad så når brugeren opgraderer til en ny grafikkortdriver? En ny musedriver? Eller laver en hjemmekompileret udgave af sin Linux-kerne (ja, NGSCB er egnet til Linux)? Så ændrer hash'ene sig. Derfor ville det kræve at et firma der udbyder software på nettet, og som gerne vil kunne stole på dem der henter det, har en gigantisk database over hash'ene de stoler på. I open-source sammenhæng ville det være helt umuligt idet brugerens egne modifikationer til fx kernen ville give en helt unik kerne som ingen altså vil stole.
En anden ting er også, at ovenstående system kun virker når man stoler på HELE operativsystemet. D.v.s. kerne, filsystemdrivere, diskdrivere, skærmdrivere o.s.v. Alle disse drivere har adgang til ALT - mange megabytes binær kode der altsammen kører i systemtilstand. Hvis blot en enkelt driver er ondsindet, kan den overtage hele computeren (ja, en driver har ligeså meget magt som selve kernen). Den vil derfor også kunne oplyse forkerte attesteringer af de kørende programmer. Selvom man som nævnt ovenfor kan verificere komponenternes identiter (og dermed driverne, hvilket giver en sikker imod ondsindede drivere) er det stadig et problem at skulle stole på SÅ meget. For sandsynligheden for at der er en buffer-overrun fejl i bare en enkelt driver er altså ret stor.
Ved Intel's Lagrande og AMD's SEM, tilføjes en ny mode hvor der indlæses en meget lille kerne. Denne kerne indlæses på en sikker måde og den er alt hvad du behøver at stole på. Denne kerne er lille nok til at den kan offentliggøres og analyseres ved formelle metoder.
Selvfølgelig kan programmer i den nye sikre tilstand få brug for diskplads o.s.v. og adgangen hertil foregår ved at der sker et kald til de "gamle" drivere inde fra den sikre tilstand. Programmerne i den sikre tilstand skal blot kryptere deres data inden disse gives til de "usikre diskdrivere". Diskdriverne i systemet kan altså højst nægte programmerne i den sikre tilstand funktionalitet, men de kan ikke få adgang til fortrolige oplysninger. Samme princip anvendes ved brug af keyboard, mus og skærm idet der forinden etableres end end-to-end krypteret forbindelse til disse enheder - men selve den krypterede kommunikation foregår gennem de almindelige drivere (som man ikke stoler på).
Da den kerne vi snakker om er så lille som den er, behøver den heller ikke at ændre sig særlig ofte. Open-source miljøet kan derfor også selv lave en sådan mini-kerne / Nexus. Hvis brugeren ændrer i den er der ganske vist ingen der stoler på den, men da den er så lille og begrænset i funktionalitet vil der ikke være noget reelt behov for at ændre i den. Man kan fortsat lave alle de modifikationer man har lyst til til Linux-kernen, det er kun Nexus'en der skal være stabil.
Med hensyn til om film/musik kan beskyttes så behøver folk ikke have netadgang for at lytte til musikken (for at tage det eksempel). De skal blot have det i forbindelse med attesteringen når de downloader den (herefter kommer musikken i NGSCB-agentens kontrol og lagres krypteret på harddisken - og kan herefter frit benyttes at det attesterede program selv når der ikke er netforbindelse).
Forresten så er det noget sludder du skriver at systemet ikke kan designes uden at Microsoft har uhindret adgang. I hvert fald tilfører det ingen ekstra risiko i forhold til i dag - snarere tværtimod! Nexus'ens kode bliver offentlig tilgængelig og er ret lille. Så faktisk er det mere sikkert end i dag hvor du lægger dine data i hænderne på programmer hvis adresserum er tilgængeligt for al Windows system-koden som du ikke kan se hvordan virker. Der kunne sagtens være en bagdør uden at du opdagede det.
Jeg kan heller ikke se hvordan det med at der bruges individuelle nøgler til multiplayerspil i dag betyder at NGSCB ikke kan få betydning for piratkopiering uden for firmaets fire vægge. For det første kan serienumre m.m. omgås (tror du selv at alle kører på lovlige klienter i dag?) og for det andet bruger private også andre programmer end spil.
Det er også en fejlslutning når du siger, at du synes behovet for at sikre mod snyd i spil ikke retfærdiggøre NGSCB. For det med spilsnyd var bare et eksempel på en ikke-ond anvendelse som jeg gav. Der er MANGE andre gode anvendelser af NGSCB. I forbindelse med al P2P er det fx interessant at klienterne kan attestere sig for hinanden sådan at man ikke kan køre med en ond klient der ødelægger netværket. I forbindelse med messenging o.s.v. er det også interessant.
Og angående Ross Andersons FAQ. Ross Anderson er en meget anerkendt kryptoekspert som jeg har stor respekt for. Desværre har han lavet en meget dårlig FAQ om TCPA/NGSCB. Der er helt fundamentale misforståelser med hensyn til hvordan TCPA/NGSCB virker. Det kommer måske delvist af at den blev skrevet på et tidspunkt hvor der ikke var meget info offentlig tilgængeligt. Nu er de VÆRSTE fejlinformationer heldigvis efterhånden taget ud af FAQ'en på grund af artikler der modsagde den oprindelige version punkt for punkt. Men der er stadig ting der er meget misvisende. Det er absolut ikke en troværdig kilde til information om disse teknologier.
Lad os bare tage en enkelt stikprøve i dit indlæg, for lige at få mig til at forstå det til bunds.
'Samme princip anvendes ved brug af keyboard, mus og skærm idet der forinden etableres end end-to-end krypteret forbindelse til disse enheder - men selve den krypterede kommunikation foregår gennem de almindelige drivere (som man ikke stoler på). '
Okay, vi har et computerspil vi skal have vist på skærmen.
Jeg har skrevet en Open Source driver til et grafikkort.
Da grafikkortet skal sørge for occlusion culling, kan jeg lade være med at culle (fjerne) noget som helst, og så tegne normaler fra alle vertexes. Derved vil jeg nemt kunne se personer der står gemt bag f. eks en mur.
Nu har vi så to situationer. Jeg har loadet Nexus kernen og den sender krypterede data til mit grafikkort. Jeg får helt forkerte vertexværdier oplyst og skærmbilledet bliver til støj (eller et meget psykadelisk multiplayerspil ;).
Den anden situation er hvor Nexus har indbygget en 3d-driver, og skærmbilledet bare bliver vist som det skal...
Men så tror jeg ikke at Nexus kernen kan være så lille og offentlig tilgængelig som du mener.
'Samme princip anvendes ved brug af keyboard, mus og skærm idet der forinden etableres end end-to-end krypteret forbindelse til disse enheder - men selve den krypterede kommunikation foregår gennem de almindelige drivere (som man ikke stoler på). '
Okay, vi har et computerspil vi skal have vist på skærmen.
Jeg har skrevet en Open Source driver til et grafikkort.
Da grafikkortet skal sørge for occlusion culling, kan jeg lade være med at culle (fjerne) noget som helst, og så tegne normaler fra alle vertexes. Derved vil jeg nemt kunne se personer der står gemt bag f. eks en mur.
Nu har vi så to situationer. Jeg har loadet Nexus kernen og den sender krypterede data til mit grafikkort. Jeg får helt forkerte vertexværdier oplyst og skærmbilledet bliver til støj (eller et meget psykadelisk multiplayerspil ;).
Den anden situation er hvor Nexus har indbygget en 3d-driver, og skærmbilledet bare bliver vist som det skal...
Men så tror jeg ikke at Nexus kernen kan være så lille og offentlig tilgængelig som du mener.
#30: For det første er din opdeling i to tilfælde ikke gyldig. Hvis Nexus'en skal sende krypteret til kortet skal det have en mini 3d-driver - altså et overlap mellem de to tilfælde.
Nå det er sagt, så er jeg ikke ekspert i hverken spilsnyd eller 3d-grafik. Det virker som om du beskriver en situation hvor man kan få grafikkortet til at vise mere end det må, ved at få driveren til at vise billederne på en bestemt måde, sådan at man kan se ting bagved.
Som det er nu Nexus'en til at kommunikere med grafikkortet via end-to-end kryptering. Der er tale om et minimalistisk API med "grimme" dialogbokse o.s.v. Det er det der som standard vil være tilgængeligt.
Man kunne dog sagtens forestille sig at fx Nvidia lavede en mini-driver der sidder inde i NGSCB-miljøet men som ikke er en del af Nexus'en. Nexus'en attesterer hvilken driver der er tale om, og en spilserver kan så vælge kun at stole på folk der bruger pågældende driver. Denne driver behøver ikke (men kan være) open source (den sidder inde i sin egen lille verden og ekspederer kommandoer udefra). Hvis du laver din egen driver er den dog ukendt for spilserveren og spilserveren kan derfor vælge ikke at stole på den. I praksis er dette iøvrigt nok ikke så relevant en problemstillingn for hverken nvidia eller ATI offentliggør deres specifikationer til 3d-funktionerne i deres kort, så ikke engang i dag kan man lave sin egen driver.
I andre sammenhænge har 3d-driveren ingen betydning, idet den ikke aktiveres og derfor behøver ens Netbank fx ikke at stole på den endsige se at man har den.
I 3d-sammenhæng vil denne driver nok ikke sende kommandoerne krypteret til grafikkortet som det er tilfældet med dialogbokse, da det vil køre for langsomt. Men nu er det der kommer til at være på skærmen heller ikke specielt hemmeligt i denne situation, så det betyder intet.
Noget andet man kunne forestille sig, og det tror jeg er mere sandsynligt, idet det ikke kræver nye drivere, er at tegningen af 3d-scenerne skete fra en 3d-engine i normal tilstand der kalder den normale driver. Selve game-enginen kører i den beskyttede tilstand sådan at brugeren ikke kan lave groft snyd som fx at tildele sig selv mere "health" eller hvad der nu findes af snyd. De to engines kommunikerer med hinanden så det hele er synkroniseret. Går man efter denne implementation vil man ikke kunne sikre sig mod det snyd der sker på driverniveau, altså ved at man får driveren til at vise mere end den må (og det er det "angreb" jeg fornemmer du snakker om). Men løsningen er nok her snarere at spillet indeholder en mekanisme, der sørger for at der ikke bliver sendt ting til driveren som brugeren ikke må se.
Men altså, det er bestemt muligt at undgå snyd med denne mekanisme.
Det er pudsigt du skriver at du vil tage en "stikprøvekontrol" af mit indlæg. Nu har du jo spurgt om specifikke ting og "anklaget" NGSCB på en række punkter, og jeg har kommenteret disse udtalelser fra dig. Så ville det da være rart med lidt feedback på hele indlægget i stedet for at du tager et enkelt afsnit ud, hvor du tror der er noget der halter og kun kommenterer på det.
Nå det er sagt, så er jeg ikke ekspert i hverken spilsnyd eller 3d-grafik. Det virker som om du beskriver en situation hvor man kan få grafikkortet til at vise mere end det må, ved at få driveren til at vise billederne på en bestemt måde, sådan at man kan se ting bagved.
Som det er nu Nexus'en til at kommunikere med grafikkortet via end-to-end kryptering. Der er tale om et minimalistisk API med "grimme" dialogbokse o.s.v. Det er det der som standard vil være tilgængeligt.
Man kunne dog sagtens forestille sig at fx Nvidia lavede en mini-driver der sidder inde i NGSCB-miljøet men som ikke er en del af Nexus'en. Nexus'en attesterer hvilken driver der er tale om, og en spilserver kan så vælge kun at stole på folk der bruger pågældende driver. Denne driver behøver ikke (men kan være) open source (den sidder inde i sin egen lille verden og ekspederer kommandoer udefra). Hvis du laver din egen driver er den dog ukendt for spilserveren og spilserveren kan derfor vælge ikke at stole på den. I praksis er dette iøvrigt nok ikke så relevant en problemstillingn for hverken nvidia eller ATI offentliggør deres specifikationer til 3d-funktionerne i deres kort, så ikke engang i dag kan man lave sin egen driver.
I andre sammenhænge har 3d-driveren ingen betydning, idet den ikke aktiveres og derfor behøver ens Netbank fx ikke at stole på den endsige se at man har den.
I 3d-sammenhæng vil denne driver nok ikke sende kommandoerne krypteret til grafikkortet som det er tilfældet med dialogbokse, da det vil køre for langsomt. Men nu er det der kommer til at være på skærmen heller ikke specielt hemmeligt i denne situation, så det betyder intet.
Noget andet man kunne forestille sig, og det tror jeg er mere sandsynligt, idet det ikke kræver nye drivere, er at tegningen af 3d-scenerne skete fra en 3d-engine i normal tilstand der kalder den normale driver. Selve game-enginen kører i den beskyttede tilstand sådan at brugeren ikke kan lave groft snyd som fx at tildele sig selv mere "health" eller hvad der nu findes af snyd. De to engines kommunikerer med hinanden så det hele er synkroniseret. Går man efter denne implementation vil man ikke kunne sikre sig mod det snyd der sker på driverniveau, altså ved at man får driveren til at vise mere end den må (og det er det "angreb" jeg fornemmer du snakker om). Men løsningen er nok her snarere at spillet indeholder en mekanisme, der sørger for at der ikke bliver sendt ting til driveren som brugeren ikke må se.
Men altså, det er bestemt muligt at undgå snyd med denne mekanisme.
Det er pudsigt du skriver at du vil tage en "stikprøvekontrol" af mit indlæg. Nu har du jo spurgt om specifikke ting og "anklaget" NGSCB på en række punkter, og jeg har kommenteret disse udtalelser fra dig. Så ville det da være rart med lidt feedback på hele indlægget i stedet for at du tager et enkelt afsnit ud, hvor du tror der er noget der halter og kun kommenterer på det.
thiim uden at vide det tror jeg igen du er ved at rode to ting sammen nemlig TCG og NGSCB så vidt jeg er orienteret er NGSCB nemlig fundamentalt forskellig fra TGC ved at basere sig på passport systemet til al signering ag betroet software.
altså således at MS eller tilsvarende suverent bestemmer hvad der må køre i beskyttet tilstand
Alt det ander du beskriver går nemlig lige så fint i spænd med IBM TCPA- til linux, hvor betroet bare kun betyder betroet af sysadmin.
Jeg er meget intereseret i at vide hvilke instanser og hvordan signerings processen rent faktisk foregår.
PS tag aldrig noget MS skriver for 100% i tråd med sandheden, specielt ikke på dette område.
Jeg er iøvrigt også meget i tvivl om hvorvidt NGSCB/TCPA nogen sinde vil kunne yde 100% garenti for at der ikke akn opstå problemer i runtime, som TCPA, chippen ikke kan beskytte imod.
Som jeg læser din beskrivelse af MS NGSCB ligner det også noget der forudsætter perfekt OS kode, for at virke. hvis OS selv kan tildele processer plads i protected-stadiet så er der vel ikke meget vunder i forhold til før?
altså således at MS eller tilsvarende suverent bestemmer hvad der må køre i beskyttet tilstand
Alt det ander du beskriver går nemlig lige så fint i spænd med IBM TCPA- til linux, hvor betroet bare kun betyder betroet af sysadmin.
Jeg er meget intereseret i at vide hvilke instanser og hvordan signerings processen rent faktisk foregår.
PS tag aldrig noget MS skriver for 100% i tråd med sandheden, specielt ikke på dette område.
Jeg er iøvrigt også meget i tvivl om hvorvidt NGSCB/TCPA nogen sinde vil kunne yde 100% garenti for at der ikke akn opstå problemer i runtime, som TCPA, chippen ikke kan beskytte imod.
Som jeg læser din beskrivelse af MS NGSCB ligner det også noget der forudsætter perfekt OS kode, for at virke. hvis OS selv kan tildele processer plads i protected-stadiet så er der vel ikke meget vunder i forhold til før?
#31
Kan du ikke give mig et link til tcpa 1.2 spec'en?
Jeg kender det originale spec og 1.1 og der er kan man ikke gøre de ting som du nævner, da alle drivere kører i kernel space. Dvs at _alle_ drivere skal være godkendt.
Det virker som om at man i 1.2 kan vælge hvilke drivere, der skal være trusted og hvilke der ikke behøves.
Grunden til at jeg tog én ting ud for at diskutere, var at jeg synes den var rimelig åbenlys svær at implementere.
Og vi kan lige så godt diskutere én ting til bunds, og så gå videre med næste område.
Jeg bliver nødt til at læse spec'en for 1.2 før jeg kan diskutere yderligere.
Kan du ikke give mig et link til tcpa 1.2 spec'en?
Jeg kender det originale spec og 1.1 og der er kan man ikke gøre de ting som du nævner, da alle drivere kører i kernel space. Dvs at _alle_ drivere skal være godkendt.
Det virker som om at man i 1.2 kan vælge hvilke drivere, der skal være trusted og hvilke der ikke behøves.
Grunden til at jeg tog én ting ud for at diskutere, var at jeg synes den var rimelig åbenlys svær at implementere.
Og vi kan lige så godt diskutere én ting til bunds, og så gå videre med næste område.
Jeg bliver nødt til at læse spec'en for 1.2 før jeg kan diskutere yderligere.
Dudsen: Dit indlæg er ret useriøst. Du starter med at skrive at du tror jeg igen blander nogle ting sammen - hvor har jeg før blandet nogle ting sammen? Citat, tak.
Desuden er TCG en arbejdsgrupe og kan derfor umuligt være det samme som NGSCB, som er en teknologi. Derfor skulle det undre mig meget om jeg havde skrevet det (du påstår jeg skulle have skrevet det var det samme). TCG udarbejder en specifikation til en hardware-enhed som godt kan fungere i sig selv og tilbyde funktionalitet (fx i IBM Thinkpads, som dog kun benytter 1.1-chips) men som i 1.2-versionen har fået nye udvidelser så den kan fungere sammen med NGSCB (som er parablyen der samler TPM, Lagrande/SEM, samt teknologier til input/output-enheder). Så de to ting hænger meget nøje sammen.
Og det du skriver med at MS suverænt kommer til at bestemme hvad der må køre er HELT ude i hampen. Det er simpelthen rent og skært forkert og hvis at din viden bygger på gæt og formodninger. Alle kan køre deres egen software i den beskyttede tilstand og endda skrive deres egen Nexus!
Du spørger også om man kan give garanti for at NGSCB er 100% sikker. Selvfølgelig kan man ikke det, og det har jeg ikke påstået noget sted, så lad være med at skrive det så det ser ud til at stå i modsætning til noget jeg har skrevet. Hvis nogle hævdede det var 100% sikkert ville de være meget useriøse.
Mest graverende i din post er dog bemærkningen:
"Som jeg læser din beskrivelse af MS NGSCB ligner det også noget der forudsætter perfekt OS kode, for at virke. hvis OS selv kan tildele processer plads i protected-stadiet så er der vel ikke meget vunder i forhold til før?"
Hele idéen med NGSCB - som jeg meget grundigt beskrev i tidligere indlæg i denne tråd - er at man IKKE forudsætter 100% perfekt OS. Man stoler kun på at Nexus'en er rigtig. OS'et tildeler ganske rigtigt pladsen i hukommelsen til Nexus'en gennem en speciel CPU instruktion hvor man angiver hvor Nexus-koden ligger og hvor meget plads der skal afsættes. Dette aktiverer en særlig procedure i CPU'en, hvor Nexus'en bliver signeret i en samarbejde mellem den og TPM'en (det er en af ting der kom med i 1.2-spec'en). Herefter kan Nexus'en ikke ændres af hoved-O/S'et. Hoved-O/S'et kan godt vælge at indlæse en anden eller en fjendtlig Nexus, men det vil andre kunne se idet signaturen fra TPM'en så ikke længere passer og den fjendtlige Nexus vil heller ikke få adgang til de secrets der ligger i TPM'en, som den gamle Nexus havde adgang til. Hoved-O/S'et har ansvaret for at få læst Nexus'en ind fra disken og aktiveret CPU-proceduren, men den kan ikke bryde sikkerheden ved at indlæse en anden Nexus.
En ting er at du helt tydeligvis har misforstået teknologien. Det kan jeg leve med. Noget andet er, at du kommer med retoriske tricks og skriver at jeg "igen" har misforstået noget, uden henvisning til hvad jeg skulle have misforstået. Det er bare SÅ lavt.
Desuden er TCG en arbejdsgrupe og kan derfor umuligt være det samme som NGSCB, som er en teknologi. Derfor skulle det undre mig meget om jeg havde skrevet det (du påstår jeg skulle have skrevet det var det samme). TCG udarbejder en specifikation til en hardware-enhed som godt kan fungere i sig selv og tilbyde funktionalitet (fx i IBM Thinkpads, som dog kun benytter 1.1-chips) men som i 1.2-versionen har fået nye udvidelser så den kan fungere sammen med NGSCB (som er parablyen der samler TPM, Lagrande/SEM, samt teknologier til input/output-enheder). Så de to ting hænger meget nøje sammen.
Og det du skriver med at MS suverænt kommer til at bestemme hvad der må køre er HELT ude i hampen. Det er simpelthen rent og skært forkert og hvis at din viden bygger på gæt og formodninger. Alle kan køre deres egen software i den beskyttede tilstand og endda skrive deres egen Nexus!
Du spørger også om man kan give garanti for at NGSCB er 100% sikker. Selvfølgelig kan man ikke det, og det har jeg ikke påstået noget sted, så lad være med at skrive det så det ser ud til at stå i modsætning til noget jeg har skrevet. Hvis nogle hævdede det var 100% sikkert ville de være meget useriøse.
Mest graverende i din post er dog bemærkningen:
"Som jeg læser din beskrivelse af MS NGSCB ligner det også noget der forudsætter perfekt OS kode, for at virke. hvis OS selv kan tildele processer plads i protected-stadiet så er der vel ikke meget vunder i forhold til før?"
Hele idéen med NGSCB - som jeg meget grundigt beskrev i tidligere indlæg i denne tråd - er at man IKKE forudsætter 100% perfekt OS. Man stoler kun på at Nexus'en er rigtig. OS'et tildeler ganske rigtigt pladsen i hukommelsen til Nexus'en gennem en speciel CPU instruktion hvor man angiver hvor Nexus-koden ligger og hvor meget plads der skal afsættes. Dette aktiverer en særlig procedure i CPU'en, hvor Nexus'en bliver signeret i en samarbejde mellem den og TPM'en (det er en af ting der kom med i 1.2-spec'en). Herefter kan Nexus'en ikke ændres af hoved-O/S'et. Hoved-O/S'et kan godt vælge at indlæse en anden eller en fjendtlig Nexus, men det vil andre kunne se idet signaturen fra TPM'en så ikke længere passer og den fjendtlige Nexus vil heller ikke få adgang til de secrets der ligger i TPM'en, som den gamle Nexus havde adgang til. Hoved-O/S'et har ansvaret for at få læst Nexus'en ind fra disken og aktiveret CPU-proceduren, men den kan ikke bryde sikkerheden ved at indlæse en anden Nexus.
En ting er at du helt tydeligvis har misforstået teknologien. Det kan jeg leve med. Noget andet er, at du kommer med retoriske tricks og skriver at jeg "igen" har misforstået noget, uden henvisning til hvad jeg skulle have misforstået. Det er bare SÅ lavt.
#33: 1.2-spec'en kommer ikke ind på disse ting, da den beskæftiger sig med TPM'en og ikke med drivere eller lignende (men du kan finde den på linket til Trusted Computing Group, som jeg sendte tidligere) - alt dette hører ind under SEM/Lagrande-systemet, da det er her man definerer den sikre udførselstilstand. Derfor undrer det mig at du skulle have læst noget om drivere i 1.1.
Specifikationerne til SEM/Lagrande er endnu ikke offentligt tilgængeligt, men i et link jeg sendte tidligere kan man læse AMD's alligevel forholdsvist detaljerede beskrivelse af SEM (indeholder fx info om nye flag og instruktioner - men uden op-koder).
Men faktisk har selv dette ikke noget med drivere at gøre.
Der er ikke noget i vejen for at have en driver kørende i sikret tilstand, for om ikke andet kan den relay'e sine I/O-operationer til en mini-port driver i den ikke-beskyttede tilstand (den skal blot sørge for at der ligger følsom info i disse operationer). Der er nemlig en kald-konvention der specificerer hvordan kald kan gå fra og til den beskyttede tilstand. På denne måde bliver driveren ikke en del af det du kalder kernen (ie Nexus'en). Sådan som jeg forventer alle Nexus bliver designede, så vil det ske på en måde sådan at den ikke vil give nogle eksterne komponenter samme rettigheder som sig selv. Nexus'en er et samlet hele, med nogle primitiver som andre så kan benytte. Derfor kan man godt lave en driver der kører i beskyttet tilstand, men den vil overfor Nexus'en ikke have status som en driver men snarere som et almindeligt program som, andre programmer i beskyttet tilstand kalder. Dette program/driver relay'er så hardware-operationer m.m. ud af den beskyttede tilstand og til den mini-port driver i ikke-beskyttet tilstand (på samme måde som at disk- og grafik- I/O gør via den ubeskyttede driver, hvilket ikke introducerer en risiko da data er krypterede). De som bruger driveren er selvfølgelig nødt til at stole på den, men de vil kunne få garanti for dens identitet. Og programmer der ikke bruger den (fx Netbank m.m.) behøver ikke stole på den, for den aktiveres først når den kaldes.
Som sagt i tidligere indlæg tror jeg ikke løsningen ligger i at have en 3d-driver kørende i beskyttet tilstand. Det ville også kræve at DirectX lå her. Det virker meget bedre at game-enginen kører i beskyttet tilstand og grafik-enginen i ikke-beskyttet, og game-enginen skal så sørge for at grafik-enginen ikke får nok information til at kunne vise noget den ikke må. Fx kunne game-enginen nægte at fortælle hvor personer står, når disse står på et sted hvor spilleren ikke kan se dem (eg bag en væg) sådan at disse slet ikke ville blive tegnet.
Man kan implementere sikkerhedsteknologien på flere lag i dette tilfælde og spørgsmålet er hvor det er mest praktisk/sikkert. Jeg er ikke ekspert i 3d-grafik og lignende og vil derfor ikke udtale mig om detye. Men der er i hvert fald ikke noget i teknologien der forhindrer nogle af mulighederne.
Specifikationerne til SEM/Lagrande er endnu ikke offentligt tilgængeligt, men i et link jeg sendte tidligere kan man læse AMD's alligevel forholdsvist detaljerede beskrivelse af SEM (indeholder fx info om nye flag og instruktioner - men uden op-koder).
Men faktisk har selv dette ikke noget med drivere at gøre.
Der er ikke noget i vejen for at have en driver kørende i sikret tilstand, for om ikke andet kan den relay'e sine I/O-operationer til en mini-port driver i den ikke-beskyttede tilstand (den skal blot sørge for at der ligger følsom info i disse operationer). Der er nemlig en kald-konvention der specificerer hvordan kald kan gå fra og til den beskyttede tilstand. På denne måde bliver driveren ikke en del af det du kalder kernen (ie Nexus'en). Sådan som jeg forventer alle Nexus bliver designede, så vil det ske på en måde sådan at den ikke vil give nogle eksterne komponenter samme rettigheder som sig selv. Nexus'en er et samlet hele, med nogle primitiver som andre så kan benytte. Derfor kan man godt lave en driver der kører i beskyttet tilstand, men den vil overfor Nexus'en ikke have status som en driver men snarere som et almindeligt program som, andre programmer i beskyttet tilstand kalder. Dette program/driver relay'er så hardware-operationer m.m. ud af den beskyttede tilstand og til den mini-port driver i ikke-beskyttet tilstand (på samme måde som at disk- og grafik- I/O gør via den ubeskyttede driver, hvilket ikke introducerer en risiko da data er krypterede). De som bruger driveren er selvfølgelig nødt til at stole på den, men de vil kunne få garanti for dens identitet. Og programmer der ikke bruger den (fx Netbank m.m.) behøver ikke stole på den, for den aktiveres først når den kaldes.
Som sagt i tidligere indlæg tror jeg ikke løsningen ligger i at have en 3d-driver kørende i beskyttet tilstand. Det ville også kræve at DirectX lå her. Det virker meget bedre at game-enginen kører i beskyttet tilstand og grafik-enginen i ikke-beskyttet, og game-enginen skal så sørge for at grafik-enginen ikke får nok information til at kunne vise noget den ikke må. Fx kunne game-enginen nægte at fortælle hvor personer står, når disse står på et sted hvor spilleren ikke kan se dem (eg bag en væg) sådan at disse slet ikke ville blive tegnet.
Man kan implementere sikkerhedsteknologien på flere lag i dette tilfælde og spørgsmålet er hvor det er mest praktisk/sikkert. Jeg er ikke ekspert i 3d-grafik og lignende og vil derfor ikke udtale mig om detye. Men der er i hvert fald ikke noget i teknologien der forhindrer nogle af mulighederne.
#34/35
Det jeg påpegede var at jeg netop at der ikke står noget om drivere i 1.1, og at jeg ikke har kunnet finde noget om 1.2.
Jeg kan godt se at mit eksempel med spil, måske ikke lige ligger inden for dit kompetanceområde og at det måske er for specifikt at diskutere.
Du siger selv at sådan noget som DirectX skal ind og ligge i nexus, før man kan undgå snyd med grafikkortet.
Det var præcis den pointe jeg ville frem til, så jeg er glad for at vi er enige.
Men en ting jeg virkelig godt kunne tænke dig du gør klart er hvilke ting der kan implementeres uden TCPA.
F. eks kan spilserveren selv fjerne spillerne når de ikke kan ses.
Men der er andre måder at man kan snyde på end lige ved at kunne se modstanderen. Man kunne forestille sig at grafikkortet blev sat til at fjerne alle lys og skygger fra scenen, så modstanderen stod tydeligere frem.
Så skulle den beskyttede del af enginen også tage sig af disse beregninger. Og tro mig, disse ting har du ikke lyst til at lave i software.
Men idéen med at have et ekstra flag på cpu'en er virkelig fristende, og åbner for mange nye muligheder.
Kan man så f. eks ikke udskifte Nexus som man vil imens computeren kører?
Det jeg påpegede var at jeg netop at der ikke står noget om drivere i 1.1, og at jeg ikke har kunnet finde noget om 1.2.
Jeg kan godt se at mit eksempel med spil, måske ikke lige ligger inden for dit kompetanceområde og at det måske er for specifikt at diskutere.
Du siger selv at sådan noget som DirectX skal ind og ligge i nexus, før man kan undgå snyd med grafikkortet.
Det var præcis den pointe jeg ville frem til, så jeg er glad for at vi er enige.
Men en ting jeg virkelig godt kunne tænke dig du gør klart er hvilke ting der kan implementeres uden TCPA.
F. eks kan spilserveren selv fjerne spillerne når de ikke kan ses.
Men der er andre måder at man kan snyde på end lige ved at kunne se modstanderen. Man kunne forestille sig at grafikkortet blev sat til at fjerne alle lys og skygger fra scenen, så modstanderen stod tydeligere frem.
Så skulle den beskyttede del af enginen også tage sig af disse beregninger. Og tro mig, disse ting har du ikke lyst til at lave i software.
Men idéen med at have et ekstra flag på cpu'en er virkelig fristende, og åbner for mange nye muligheder.
Kan man så f. eks ikke udskifte Nexus som man vil imens computeren kører?
#34 du svarer ikke på mit spørgsmål hvad er forskellen på NGSCB og TPM'en.
TCPA/TGC er en arbejdsgruppe det er jeg sku godt klar over men er absolut ikke ikke sikker på at NGSCB er deres "opfindelse".
Det er der jeg syntes du forveksler tingende TGC har svjv intet med udviklingen af NGSCB at gøre.
Så vidt jeg ved er NGSCB(det der tidlige hed paladium) MS forsøg på at gøre brug af TPM-chippen.
Som jeg ser det er der to dele af TPM/NGSCB teknologierne.
1 en hardware enhed der tjækker om OS og aplikationer passer til en bestemt signatur, dette er pæn og ren sikkerhedsteknologi.
2 og der er her det bliver meget uklart, en måde hvorpå omverdenen kan se om du kører trusted software, underforstået at brugeren ikke selv har ret til dette har som jeg ser det ingen praktisk betydning rent sikkerhedsmæssigt, men er rendyrket forbruger chikane.
Det kan godt værre jeg roder lidt rundt i hvornår i er ude efter sikkerhed og hvornår i taler om hvem der er betroede medlemmer af samfundet.
Ligger der ikke en eller anden form for "borgerkort" i NGSCB-arkitekturen altså således at folk der pænt holder sig inden for en defineret spektrum af software er gode borgere mens folk der kører med uoficielt og mdificeret software er uden for det gode selvskab.
Det er denne del der svjv er kun er en del af NGSCB(og ikke noget TGC arbejder for) der for folk til at lægge i kakkelovnen til en lynchning.
TCPA/TGC er en arbejdsgruppe det er jeg sku godt klar over men er absolut ikke ikke sikker på at NGSCB er deres "opfindelse".
Det er der jeg syntes du forveksler tingende TGC har svjv intet med udviklingen af NGSCB at gøre.
Så vidt jeg ved er NGSCB(det der tidlige hed paladium) MS forsøg på at gøre brug af TPM-chippen.
Som jeg ser det er der to dele af TPM/NGSCB teknologierne.
1 en hardware enhed der tjækker om OS og aplikationer passer til en bestemt signatur, dette er pæn og ren sikkerhedsteknologi.
2 og der er her det bliver meget uklart, en måde hvorpå omverdenen kan se om du kører trusted software, underforstået at brugeren ikke selv har ret til dette har som jeg ser det ingen praktisk betydning rent sikkerhedsmæssigt, men er rendyrket forbruger chikane.
Det kan godt værre jeg roder lidt rundt i hvornår i er ude efter sikkerhed og hvornår i taler om hvem der er betroede medlemmer af samfundet.
Ligger der ikke en eller anden form for "borgerkort" i NGSCB-arkitekturen altså således at folk der pænt holder sig inden for en defineret spektrum af software er gode borgere mens folk der kører med uoficielt og mdificeret software er uden for det gode selvskab.
Det er denne del der svjv er kun er en del af NGSCB(og ikke noget TGC arbejder for) der for folk til at lægge i kakkelovnen til en lynchning.
#36: Spilserveren kan formentlig godt skjule andre spillere for hinanden uden TCPA - men nu var det dig selv der gav dette eksempel, så det var det jeg svarede på! Den form for snyd jeg nu havde i tankerne var snyd hvor spilleren fx sætter computeren til at spille for sig eller misbruger oplysninger om spilstatus - eller decideret udnytter svagheder i spilprotekollen (som er meget svære at undgå, idet hver computer sidder med sin egen spiltilstand - der er jo et delay imellem synkroniseringer). Dette her er en måde at sikre på at ALLE kører med de samme klienter.
Nu nævner du eksempel med fjernelse lys og skygger og det mener jeg må være helt ækvivalent med det eksempel du gav før. Jeg vil slet ikke gå ind i detaljerne med hensyn til 3d-grafik, men min pointe var at der teknisk ikke er noget i vejen for at flytte fx DirectX og 3d-driveren ind i miljøet. Men det kræver så at spilserveren også stoler på de versioner, og det kan blive bøvlet. Jeg skrev på intet tidspunkt at noget skulle implementeres i software.
Med hensyn til at skifte Nexus så kan Nexus'en loades og unloades mens hoved-O/S'et kører, så det loades kun når der er brug for det. Man kan også indlæse andre (jeg ved ikke om det bliver en officiel funktion i Windows, men om ikke andet kan det gøres i Linux - det er ikke hardwaren der forhindrer det) Nexus'er men de forskellige Nexus'er kan ikke få adgang til hinandens oplysninger i TPM'en (og dette sikres af TPM'en på en "sikker måde" ved check af hashen).
Nu nævner du eksempel med fjernelse lys og skygger og det mener jeg må være helt ækvivalent med det eksempel du gav før. Jeg vil slet ikke gå ind i detaljerne med hensyn til 3d-grafik, men min pointe var at der teknisk ikke er noget i vejen for at flytte fx DirectX og 3d-driveren ind i miljøet. Men det kræver så at spilserveren også stoler på de versioner, og det kan blive bøvlet. Jeg skrev på intet tidspunkt at noget skulle implementeres i software.
Med hensyn til at skifte Nexus så kan Nexus'en loades og unloades mens hoved-O/S'et kører, så det loades kun når der er brug for det. Man kan også indlæse andre (jeg ved ikke om det bliver en officiel funktion i Windows, men om ikke andet kan det gøres i Linux - det er ikke hardwaren der forhindrer det) Nexus'er men de forskellige Nexus'er kan ikke få adgang til hinandens oplysninger i TPM'en (og dette sikres af TPM'en på en "sikker måde" ved check af hashen).
Dudsen (#34): Nu er du altså ved at gå mig på nerverne. Prøver du bevidst at forplumre diskussionen? Du er i hvert fald ikke god til at læse mine indlæg.
Lad mig bare tage det første du skriver:
"du svarer ikke på mit spørgsmål hvad er forskellen på NGSCB og TPM'en.
TCPA/TGC er en arbejdsgruppe det er jeg sku godt klar over men er absolut ikke ikke sikker på at NGSCB er deres "opfindelse".
Det er der jeg syntes du forveksler tingende TGC har svjv intet med udviklingen af NGSCB at gøre."
NGSCB er IKKE TCG's opfindelse! Det har jeg ikke skrevet noget som helst sted. Jeg synes faktisk jeg ret detaljeret har gjort klart hvad forholdet er mellem de to teknologier (ovenikøbet i mit sidste indlæg til dig).
Historisk set er det forløbet således: Først kom TCPA. De skrev specifikationer (1.0-1.1) til en chip (TPM'en) som skulle tilbyde secure key storage samt nogle andre funktioner som man skulle kunne have glæde af uden noget andet hardware. Denne chip er havnet i en række computere og bliver brugt allerede i dag. Men der er nogle af funktionerne i TPM'en (nemlig PCR-registre som lægger op til en chain-of-trust) som viste sig upraktiske til formålet. Jeg har meget detaljeret gennemgået hvorfor det var upraktisk, i tidligere indlæg som svar til Iean, og jeg vil ikke gentage dette.
Microsoft indså det var upraktisk og har i samarbejde med AMD, Intel fået lavet nogle udvidelser til CPU og chipsæt som gør det nemmere at sikre identiteten af software. For at dette kan fungere kræves dog mindst 1 ekstra funktion af TPM'en og dette er så blevet indføjet i specifikation 1.2 lavet af TCG (udbrydergruppen af TCPA). Denne ekstra-funktion består i at TPM'en kan verificere identiteten af en Nexus og har seperat storage til hver Nexus. AMD's udvidelser til CPU og chipsæt hedder SEM og Intel's hedder LaGrande.
Og hvad er så NGSCB? NGSCB står for Next-Generation Secure Computing Base og er Microsofts navn for en ny PC-platform der indeholder:
1) En version >=1.2 TPM
2) CPU+chipsæt compliant med LaGrande/SEM
3) Krypteret kommunikation med grafikkort
4) Krypteret kommunikation med mus, tastatur
5) Et operativsystem der understøtter disse nye hardwarefaciliteter.
NGSCB er et parably-begreb for alle disse teknologier. Microsofts har fået sat en masse i spil på forskellige fronter (AMD/Intel, TCG, NVidia, ATI (muligvis også andre grafikkortproducenter, og producenter af input/output-enheder m.m.) og dette skal alt sammen munde ud i "en ny PC" der er andet og mere end bare det TPM'en tilbyder.
Så altså, NGSCB er en teknologi der involverer TPM'en (>= 1.2) PLUS en del andet hardware.
Der er intet af dette der er i modstrid med noget jeg tidligere har skrevet (faktisk har jeg skrevet præcis dette) så jeg roder altså ikke noget sammen, som du siger. Indrøm dette eller kom med et citat, tak.
Jeg vil ikke svare på resten af dit indlæg, for spørgsmålene kommer sig af misforståelser af teknologien.
Lad mig bare tage det første du skriver:
"du svarer ikke på mit spørgsmål hvad er forskellen på NGSCB og TPM'en.
TCPA/TGC er en arbejdsgruppe det er jeg sku godt klar over men er absolut ikke ikke sikker på at NGSCB er deres "opfindelse".
Det er der jeg syntes du forveksler tingende TGC har svjv intet med udviklingen af NGSCB at gøre."
NGSCB er IKKE TCG's opfindelse! Det har jeg ikke skrevet noget som helst sted. Jeg synes faktisk jeg ret detaljeret har gjort klart hvad forholdet er mellem de to teknologier (ovenikøbet i mit sidste indlæg til dig).
Historisk set er det forløbet således: Først kom TCPA. De skrev specifikationer (1.0-1.1) til en chip (TPM'en) som skulle tilbyde secure key storage samt nogle andre funktioner som man skulle kunne have glæde af uden noget andet hardware. Denne chip er havnet i en række computere og bliver brugt allerede i dag. Men der er nogle af funktionerne i TPM'en (nemlig PCR-registre som lægger op til en chain-of-trust) som viste sig upraktiske til formålet. Jeg har meget detaljeret gennemgået hvorfor det var upraktisk, i tidligere indlæg som svar til Iean, og jeg vil ikke gentage dette.
Microsoft indså det var upraktisk og har i samarbejde med AMD, Intel fået lavet nogle udvidelser til CPU og chipsæt som gør det nemmere at sikre identiteten af software. For at dette kan fungere kræves dog mindst 1 ekstra funktion af TPM'en og dette er så blevet indføjet i specifikation 1.2 lavet af TCG (udbrydergruppen af TCPA). Denne ekstra-funktion består i at TPM'en kan verificere identiteten af en Nexus og har seperat storage til hver Nexus. AMD's udvidelser til CPU og chipsæt hedder SEM og Intel's hedder LaGrande.
Og hvad er så NGSCB? NGSCB står for Next-Generation Secure Computing Base og er Microsofts navn for en ny PC-platform der indeholder:
1) En version >=1.2 TPM
2) CPU+chipsæt compliant med LaGrande/SEM
3) Krypteret kommunikation med grafikkort
4) Krypteret kommunikation med mus, tastatur
5) Et operativsystem der understøtter disse nye hardwarefaciliteter.
NGSCB er et parably-begreb for alle disse teknologier. Microsofts har fået sat en masse i spil på forskellige fronter (AMD/Intel, TCG, NVidia, ATI (muligvis også andre grafikkortproducenter, og producenter af input/output-enheder m.m.) og dette skal alt sammen munde ud i "en ny PC" der er andet og mere end bare det TPM'en tilbyder.
Så altså, NGSCB er en teknologi der involverer TPM'en (>= 1.2) PLUS en del andet hardware.
Der er intet af dette der er i modstrid med noget jeg tidligere har skrevet (faktisk har jeg skrevet præcis dette) så jeg roder altså ikke noget sammen, som du siger. Indrøm dette eller kom med et citat, tak.
Jeg vil ikke svare på resten af dit indlæg, for spørgsmålene kommer sig af misforståelser af teknologien.
#39 s
Jeg kan ved nærmere gennemlæsning godt se at du på intet tidpunkt ser TPM'en som en ren sikkerheds teknologi, men kon som en DRM-chip(en fritz chip), mit problem er så at jeg for ca et år siden læste et par IBM whitepapers der fremstillede TPM'en helt anderledes, nemlig som et værktøj en sysadmin kunne bruge til at begrense root kits og den slags.
Og ved gennemlæsning af pressemedelelser fra TGC ser det ud til at dette er deres visioner, jeg ser intet om DRM features.
Så vidt jeg kan vurdere handler alle de tilføjelser MS har bragt på banen i forbindelse med NGSCB(der er identisk med paladium) udelukkende om DRM og div forbruger chikane, ikke om sikkerheds delen.
Jeg tror at det er det hvor vi går galt af hinaden jeg har nemlig opfattet TPM'en som en ting der i TCPA-regi primært handlede om personlig sikkerhed.
Jeg kan ved nærmere gennemlæsning godt se at du på intet tidpunkt ser TPM'en som en ren sikkerheds teknologi, men kon som en DRM-chip(en fritz chip), mit problem er så at jeg for ca et år siden læste et par IBM whitepapers der fremstillede TPM'en helt anderledes, nemlig som et værktøj en sysadmin kunne bruge til at begrense root kits og den slags.
Og ved gennemlæsning af pressemedelelser fra TGC ser det ud til at dette er deres visioner, jeg ser intet om DRM features.
Så vidt jeg kan vurdere handler alle de tilføjelser MS har bragt på banen i forbindelse med NGSCB(der er identisk med paladium) udelukkende om DRM og div forbruger chikane, ikke om sikkerheds delen.
Jeg tror at det er det hvor vi går galt af hinaden jeg har nemlig opfattet TPM'en som en ting der i TCPA-regi primært handlede om personlig sikkerhed.
#40: Jeg ser bestemt TPM'en som en sikkerhedsteknologi! Personlig sikkerhed er den vigtigste ting den tilbyder. Fx et secure key storage hvor nøgler til netbank ligger i TPM'en. De kan bruges til at signe med men kan ikke eksporteres (med mindre brugeren ønsker det) så en virus kan ikke grave nøglen ud og sende den til sin ejermand.
eg ved ikke hvilken nærlæsning af mine indlæg der har ført dig til at sige, at jeg ser dette som en DRM-teknologi og ikke en sikkerhedsteknologi.
Det jeg skrev var, at den ikke er 100% sikker overfor alle hardware indgreb. Det ville være mystisk hvis nogen hævdede andet. Og dette faktum tæller faktisk til fordel for anti-DRM lobbyen snarere end det omvendte.
Attestering af programmer har iøvrigt også store fordele for selve brugeren.
Jeg vil gerne have mig frabedt dine mystiske citater af mine indlæg. I denne tråd har du flere gange forsøgt at citere mig for noget jeg ikke har sagt, du har brugt retoriske tricks ved at sige at jeg "igen" har misforstået noget, uden at sige noget om hvad første misforståelse skulle gå på. Dine beskyldninger angående anden misforståelse viste sig slet ikke at være en misforståelse fra min side men simpelthen opdigtning af noget jeg skulle have skrevet. Jeg har udbedt mig citater af disse påståede misforståelser men har intet fået. Jeg har udbedt mig indrymmelse af at DU tog fejl - det har jeg ikke fået. Alt dette springer du bare let og elegant over.
Summa sumarum, så har din opførsel i denne diskussion været særdeles barnlig. Du har med dine indlæg ikke dokumenteret andet end din manglende indsigt i teknologien.
eg ved ikke hvilken nærlæsning af mine indlæg der har ført dig til at sige, at jeg ser dette som en DRM-teknologi og ikke en sikkerhedsteknologi.
Det jeg skrev var, at den ikke er 100% sikker overfor alle hardware indgreb. Det ville være mystisk hvis nogen hævdede andet. Og dette faktum tæller faktisk til fordel for anti-DRM lobbyen snarere end det omvendte.
Attestering af programmer har iøvrigt også store fordele for selve brugeren.
Jeg vil gerne have mig frabedt dine mystiske citater af mine indlæg. I denne tråd har du flere gange forsøgt at citere mig for noget jeg ikke har sagt, du har brugt retoriske tricks ved at sige at jeg "igen" har misforstået noget, uden at sige noget om hvad første misforståelse skulle gå på. Dine beskyldninger angående anden misforståelse viste sig slet ikke at være en misforståelse fra min side men simpelthen opdigtning af noget jeg skulle have skrevet. Jeg har udbedt mig citater af disse påståede misforståelser men har intet fået. Jeg har udbedt mig indrymmelse af at DU tog fejl - det har jeg ikke fået. Alt dette springer du bare let og elegant over.
Summa sumarum, så har din opførsel i denne diskussion været særdeles barnlig. Du har med dine indlæg ikke dokumenteret andet end din manglende indsigt i teknologien.
#41
Vil sige at jeg ved nærmere læsning er blevet mindre skeptisk overfor TCPA, men er ikke helt tryg ved MS' Palladium/(Den der forkortelse jeg aldrig kan huske.. :D
For mit vedkommende vil jeg fortrække, at det bliver et uafhængigt konsortium.
Hvis endelig det skal trækkes ned over hovederne på os.
Den sidste reservetion jeg har, er at det vil kunne misbruges til DRM formål.
Ikke at det behøver at udgøre et problem, men det vil højest sandsynligt fjerne folk fair-use muligheder fuldstændigt.
Hvis jeg kan få et RENT sikkerhedssystem, på mine præmisser, så kan jeg godt leve med det.
Vil sige at jeg ved nærmere læsning er blevet mindre skeptisk overfor TCPA, men er ikke helt tryg ved MS' Palladium/(Den der forkortelse jeg aldrig kan huske.. :D
For mit vedkommende vil jeg fortrække, at det bliver et uafhængigt konsortium.
Hvis endelig det skal trækkes ned over hovederne på os.
Den sidste reservetion jeg har, er at det vil kunne misbruges til DRM formål.
Ikke at det behøver at udgøre et problem, men det vil højest sandsynligt fjerne folk fair-use muligheder fuldstændigt.
Hvis jeg kan få et RENT sikkerhedssystem, på mine præmisser, så kan jeg godt leve med det.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund