---

Findes der nogle gode måder at sikre indholdet på medarbejdernes
bærbare, kryptering?

Jeg har hørt noget om at der er en "sikkerhedschip" i IBM'erne, men kan
den bruges til noget fornuftingt?

Kan det styres centralt?
Evt generelle erfaringer?

Mvh
Martin

---

Martin wrote:
>
> Findes der nogle gode måder at sikre indholdet på medarbejdernes
> bærbare, kryptering?

Hvad skal de sikres imod? Kryptering kan være en god idé
hvis man er bekymret for om dataene kan falde i forkerte
hænder. Software og hardware til kryptering af en hel
disk er generelt ikke særlig godt. Den eneste undtagelse
er vist GBDE som ser ud til at være ret sikker i de
fleste scenarier.

>
> Jeg har hørt noget om at der er en "sikkerhedschip" i IBM'erne, men kan
> den bruges til noget fornuftingt?

Hvad er det for en chip? En chip der kan lave AES i
hardware ville sikkert kunne hjælpe på performance. Man
skal dog lige være opmærksom på at i nogle tilfælde kan
sådan noget hardware kræve at data ryger en ekstra gang
frem og tilbage over PCI bussen i stedet for at blive
behandlet i CPUen.

Kryptering direkte i controller eller disk ville være
smart, hvis kvaliteten var i orden. Desværre lader det
ikke til at være tilfældet med eksisterende hardware
implementationer.

--
Kasper Dupont
Note to self: Don't try to allocate
256000 pages with GFP_KERNEL on x86.

---

Kasper Dupont wrote:
> Martin wrote:
>
>>Findes der nogle gode måder at sikre indholdet på medarbejdernes
>>bærbare, kryptering?
>
>
> Hvad skal de sikres imod? Kryptering kan være en god idé
> hvis man er bekymret for om dataene kan falde i forkerte
> hænder. Software og hardware til kryptering af en hel
> disk er generelt ikke særlig godt. Den eneste undtagelse
> er vist GBDE som ser ud til at være ret sikker i de
> fleste scenarier.
>
>
>>Jeg har hørt noget om at der er en "sikkerhedschip" i IBM'erne, men kan
>>den bruges til noget fornuftingt?
>
>
> Hvad er det for en chip? En chip der kan lave AES i
> hardware ville sikkert kunne hjælpe på performance. Man
> skal dog lige være opmærksom på at i nogle tilfælde kan
> sådan noget hardware kræve at data ryger en ekstra gang
> frem og tilbage over PCI bussen i stedet for at blive
> behandlet i CPUen.
>
> Kryptering direkte i controller eller disk ville være
> smart, hvis kvaliteten var i orden. Desværre lader det
> ikke til at være tilfældet med eksisterende hardware
> implementationer.
>
Der er kun tale om kryptering, således at data er sikret ved tyveri.

Hvad findes der af software/hardware som kunne løse denne opgave?

Mvh
Martin

---

Martin wrote:

>>>Findes der nogle gode måder at sikre indholdet på medarbejdernes
>>>bærbare, kryptering?
> Der er kun tale om kryptering, således at data er sikret ved tyveri.
>
> Hvad findes der af software/hardware som kunne løse denne opgave?

Linux med CryptoLoop er et bud.

--
M.V.H
Christian Iversen

---

Christian Iversen wrote:
>
> Linux med CryptoLoop er et bud.

Men FreeBSD med GBDE er et bedre bud. Jeg
tror endnu ikke der findes nogen anden
implemenation, der kommer op på højde med
GBDE hvad angår sikkerheden.

--
Kasper Dupont
Note to self: Don't try to allocate
256000 pages with GFP_KERNEL on x86.

---

Kasper Dupont wrote:
> Christian Iversen wrote:
>
>>Linux med CryptoLoop er et bud.
>
>
> Men FreeBSD med GBDE er et bedre bud. Jeg
> tror endnu ikke der findes nogen anden
> implemenation, der kommer op på højde med
> GBDE hvad angår sikkerheden.

Linux har allerede skiftes cryptoloop ud med et devicemapper/LVM baseret
system. Det skulle addressere nogle af problemerne med crytoloop bl.a.
IV valg.
Jeg har ikke kigget på det i detaljer.

Peter

---

Peter Mogensen wrote:
>
> Linux har allerede skiftes cryptoloop ud med et devicemapper/LVM baseret
> system. Det skulle addressere nogle af problemerne med crytoloop bl.a.
> IV valg.
> Jeg har ikke kigget på det i detaljer.

OK, så bliver jeg nok nødt til selv at kigge lidt
på detaljerne engang indenfor den nærmeste fremtid.

--
Kasper Dupont
Note to self: Don't try to allocate
256000 pages with GFP_KERNEL on x86.

---

Kasper Dupont wrote:
> OK, så bliver jeg nok nødt til selv at kigge lidt
> på detaljerne engang indenfor den nærmeste fremtid.
>

http://www.saout.de/misc/dm-crypt/

Det ser ud til at det indtil videre blot er bagudkompatibelt med
crytoloop, men de er bevidst om problemerne.

Peter

---

Peter Mogensen wrote:
>
> Kasper Dupont wrote:
> > OK, så bliver jeg nok nødt til selv at kigge lidt
> > på detaljerne engang indenfor den nærmeste fremtid.
> >
>
> http://www.saout.de/misc/dm-crypt/
>
> Det ser ud til at det indtil videre blot er bagudkompatibelt med
> crytoloop, men de er bevidst om problemerne.

OK, det fremgår ikke af den side om frameworket overhovedet
tillader et ægte tilfældigt IV. Cryptoloop gav et framework,
hvor man nemt kunne skifte til en bedre deterministisk IV
generering, men der var ingen mulighed for et tilfældigt IV.
Eksisterer denne mulighed med dm-crypt?

--
Kasper Dupont
Note to self: Don't try to allocate
256000 pages with GFP_KERNEL on x86.

---

Kasper Dupont wrote:
> OK, det fremgår ikke af den side om frameworket overhovedet
> tillader et ægte tilfældigt IV.

Næe, men han antyder da at der er rige uligheder for fremtidige udvidelser.

> Cryptoloop gav et framework,
> hvor man nemt kunne skifte til en bedre deterministisk IV
> generering, men der var ingen mulighed for et tilfældigt IV.
> Eksisterer denne mulighed med dm-crypt?

Definer "tilfældigt" :)
Så vidt jeg kan se, så er der endnu ikke mulighed for fuldstændig
tilfældigt IV, men denne side oplister vist state-of-the-art:

http://clemens.endorphin.org/LinuxHDEncSettings

Peter

---

Peter Mogensen wrote:
>
> Så vidt jeg kan se, så er der endnu ikke mulighed for fuldstændig
> tilfældigt IV, men denne side oplister vist state-of-the-art:
>
> http://clemens.endorphin.org/LinuxHDEncSettings

Den giver nok et meget godt billede af state-of-the-art indenfor
diskkrypteringer med en 1:1 korrespondance mellem logiske og
fysiske sektorer, hvilket betyder der kun ses på deterministiske
krypteringer uden integritetscheck.

Hvis man opgiver kravet om 1:1 korrespondance mellem logiske og
fysiske sektorer og i stedet accepterer, at krypteringen fylder
lidt ekstra, så kan man lave noget mere sikkert.

Og faktisk tror jeg CPU forbruget ved en ægte CBC kryptering med
tilfældigt IV er mindre end nogle af disse "hacks", der bruges
for at begrænse skaderne ved et deterministisk IV. Ulemperne er
den lidt forringede I/O performance og manglen på atomare
opdateringer. Opdateringsproblemet kan løses, men koster
yderligere I/O performance.

Som tidligere nævnt er GBDE mig bekendt den eneste implementation
af probabilistisk diskkryptering, ikke dermed sagt at den er
perfekt, men den er nok lidt mere state-of-the-art end alle de
deterministiske.

Overvejelserne omkring malleable encryptions var jeg igennem for
tre år siden, og jeg endte med at indse, at den korrekte løsning
var at indføre en mere gennemgående integritet. En dekryptering
der spytter skrald ud er ikke godt nok, hvis der er ændret på
krypteringen skal det detekteres ved dekryptering og en passende
fejlkode sendes til næste lag.

Desværre ser integritet i en diskkryptering ud til at være lidt
dyrt i performance. Men det skal man passe på med at sige noget
endegyldigt om før der er nogen som prøver at implementere det.

--
Kasper Dupont
Note to self: Don't try to allocate
256000 pages with GFP_KERNEL on x86.

---

In article <43135007$0$18648$14726298@news.sunsite.dk>, Martin wrote:
> Findes der nogle gode måder at sikre indholdet på medarbejdernes
> bærbare, kryptering?
>
> Jeg har hørt noget om at der er en "sikkerhedschip" i IBM'erne, men kan
> den bruges til noget fornuftingt?
>
> Kan det styres centralt?
> Evt generelle erfaringer?

Har ikke hørt om noget der taler med AD endnu. Alle produkter går ud fra
at det er en medarbejder + nogle systemfolk der har adgang. Typisk max
10 brugernavne/passwords. Ingen password sync. Men man kan vist rulle nye
ud under Windows i nogle af de dyre produkter.

---

Jag har begränsad erfarenhet av security-chipet.

CompuSec har en 'free offering' jag hört och läst gott om, men icke provat.

Själv använder jag TrueCrypt. Nackdelen är att den inte kan kryptera
Windows-partitionen,
men i övrigt är den - såvitt jag kan bedöma - säker och lättanvänd. En sak
jag tycker om är
'traveller mode' som är utmärkt att skydda små flyttbara media såsom CF-kort
och USB-sticks med.

mvh Pelle

---

Per Nyman wrote:
>
> Själv använder jag TrueCrypt.

TrueCrypt bruger dårlige IV til sin CBC mode kryptering. Hvis
ikke man er klar over hvad konsekvenser det kan have, så bør
man nok lede efter noget bedre end TrueCrypt. Hvis det lykkes
at finde noget bedre, så lad os høre om det.

--
Kasper Dupont
Note to self: Don't try to allocate
256000 pages with GFP_KERNEL on x86.

---

Martin wrote:
> Findes der nogle gode måder at sikre indholdet på medarbejdernes
> bærbare, kryptering?

Som Kasper spurgte: Sikres imod hvad?

> Jeg har hørt noget om at der er en "sikkerhedschip" i IBM'erne, men kan
> den bruges til noget fornuftingt?

Chippen er en "Trusted platform module", som bl.a. kan RSA og lagre
nøgler. Den kan umiddelbart løse det samme som et smartcard kan. (og
nogle lidt mere kontroversielle ting).

Jeg ved ikke hvilket software, der følger med, men IBM har frigivet en
device-driver for Linux:
http://researchweb.watson.ibm.com/gsal/tcpa/TPM-2.0.tar.gz

Du kan iøvrigt komme langt hen ad vejen (forhindre at tyve får adgang
til dine data) uden sådan en chip ved bare generelt at kryptere dit
filsystem.

Peter

---

Hvad med http://www.pcdynamics.com/SafeHouse/

eller http://www.qdsecurity.com/clevercrypt.html

Det må da være perfekt til at sikre data?!

Bryllupsspecialisten

---

Bryllupsspecialisten wrote:
>
> Hvad med http://www.pcdynamics.com/SafeHouse/

Den understøtter Blowfish, Twofish, Rijndael og DES.
Med det udvalg af ciphers ville jeg nok vælge Rijndael.
Man bør i hvert fald ikke bruge blowfish eller DES.

Gad vide hvorfor de skriver Rijndael og ikke AES?
Implementerer de den fulde Rijndael inklusiv support
for større cipher blokke?

Desværre står der ikke en lyd om hvilken mode de bruger.
Og det er netop på det punkt hvor langt de fleste
implementationer har svagheder.

>
> eller http://www.qdsecurity.com/clevercrypt.html

1280 bits kryptering, må jeg godt grine nu? De nævnte
ciphers har blokstørrelser på hhv. 64 og 128 bits.

--
Kasper Dupont
Note to self: Don't try to allocate
256000 pages with GFP_KERNEL on x86.

---

On 2005-08-30, Kasper Dupont <kasperd@daimi.au.dk> wrote:
> 1280 bits kryptering, må jeg godt grine nu? De nævnte
> ciphers har blokstørrelser på hhv. 64 og 128 bits.

Det ser ud som om de anvender flere forskellige krypteringsformer på
data og dermed fremkommer på magisk vis tallet 1280:

http://www.qdsecurity.com/clevercrypt-algorithms.html

Hvorvidt dette øger sikkerheden har jeg ikke nok indsigt til at tage
stilling til.

--
Med venlig hilsen
- Jacob Atzen

---

Jacob Atzen wrote:
>
> On 2005-08-30, Kasper Dupont <kasperd@daimi.au.dk> wrote:
> > 1280 bits kryptering, må jeg godt grine nu? De nævnte
> > ciphers har blokstørrelser på hhv. 64 og 128 bits.
>
> Det ser ud som om de anvender flere forskellige krypteringsformer på
> data og dermed fremkommer på magisk vis tallet 1280:
>
> http://www.qdsecurity.com/clevercrypt-algorithms.html
>
> Hvorvidt dette øger sikkerheden har jeg ikke nok indsigt til at tage
> stilling til.

Det vil heller ikke hjælpe i dette tilfælde. For selv hvis man
har den tekniske indsigt er oplysningerne på siden er for
mangelfulde til, at man kan vurdere sikkerheden af deres
løsning.

Hvis ellers cipherne er sammensat på den rigtige måde, så har
man garanti for, at den samlede konstruktion er lige så sikker
som den stærkeste cipher. Det vil sige hvis en af cipherne
bliver knækket, så er man stadig på den sikre side, selvom man
ikke på forhånd kunne forudsige hvilken, der ville blive
knækket.

Men som jeg allerede har påpeget, så har de valgte ciphers
ikke så store cipher blokke. Det fremgår intet sted, hvad de
har gjort for at undgå birthday attacks.

--
Kasper Dupont
Note to self: Don't try to allocate
256000 pages with GFP_KERNEL on x86.

---

Den Mon, 29 Aug 2005 22:44:56 +0200 skrev Peter Mogensen:
> Martin wrote:
>> Findes der nogle gode måder at sikre indholdet på medarbejdernes
>> bærbare, kryptering?
>
> Som Kasper spurgte: Sikres imod hvad?
>
>> Jeg har hørt noget om at der er en "sikkerhedschip" i IBM'erne, men kan
>> den bruges til noget fornuftingt?
>
> Chippen er en "Trusted platform module", som bl.a. kan RSA og lagre
> nøgler. Den kan umiddelbart løse det samme som et smartcard kan. (og
> nogle lidt mere kontroversielle ting).

Proppes i lommen?

Er det ikke cirka den eneste fordel smartcards har i forhold til
software? Krypteringen der kan implementeres er jo under alle
omstændigheder blot matematik, der kan implementeres i software, og du
skal ikke bilde mig ind at et smartcard er hurtigere til at udføre
krypteringen end en P4 - Med de clockfrekvenser en P4 er oppe på ville
plastickortet nok smelte.

Hvordan sikkerheden er i smartcards (udover muligheden for at holde
dem i lommen), kan vi jo evt. spørge Viasat om, det har de mange års
erfaring i

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
> Proppes i lommen?

http://www.eff.org/Infrastructure/trusted_computing/20031001_tc.php


> Er det ikke cirka den eneste fordel smartcards har i forhold til
> software?

Njarh... smartcard prøver jo også på at gøre det umuligt at den private
nøgle kan forlade kortet. Det kan du ikke med software.

Peter

---

Den Tue, 30 Aug 2005 19:09:06 +0200 skrev Peter Mogensen:
> Kent Friis wrote:
>> Proppes i lommen?
>
> http://www.eff.org/Infrastructure/trusted_computing/20031001_tc.php
>
>
>> Er det ikke cirka den eneste fordel smartcards har i forhold til
>> software?
>
> Njarh... smartcard prøver jo også på at gøre det umuligt at den private
> nøgle kan forlade kortet. Det kan du ikke med software.

Med vægt på "prøver".

Hvor effektivt det er, kan du jo prøve at spørge Viasat om.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
> Hvor effektivt det er, kan du jo prøve at spørge Viasat om.

Viasat har følgende imod sig:

1) Stor datamængde - kanalerne der bære videosignalerne.

2) Klartekst udgaven kan købes - køb et lovligt kort.

3) Håndtering af fejl i modtagelsen.

4) Billig dekoder.

---

Den Tue, 30 Aug 2005 21:43:23 +0200 skrev Christian E. Lysel:
> Kent Friis wrote:
>> Hvor effektivt det er, kan du jo prøve at spørge Viasat om.
>
> Viasat har følgende imod sig:
>
> 1) Stor datamængde - kanalerne der bære videosignalerne.

Kortet dekrypterer ikke (eller gjorde i hvert fald ikke på D2-Mac)
selve signalerne, men kun en den kode der skal bruges til at
dekode signalerne. Det var en kode per to et halvt sekund, SVJH, altså
meget mindre end data-mængden i selve video-signalet.

> 2) Klartekst udgaven kan købes - køb et lovligt kort.

Jeg troede egentlig at krypterings-algoritmer forhindrede at finde
nøglen ved at sammenligne ciphertekst og klartekst - er det ikke hele
fidusen?

> 3) Håndtering af fejl i modtagelsen.

1. Error-correction før bit-streamen når dekrypterings-delen. 2. Intet
billede de næste to et halvt sekund, hvis error-correction'en ikke
er nok.

> 4) Billig dekoder.

Ikke nødvendig for at kommunikere med et smartcard, da der er tale om
et standard-interface (iso-et eller andet, mener jeg).

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
> Jeg troede egentlig at krypterings-algoritmer forhindrede at finde
> nøglen ved at sammenligne ciphertekst og klartekst - er det ikke hele
> fidusen?

Nej. Man har jo kun ciphertekst/klartekst fordi der er en
krypteringsalgoritme.
Hvor effektivt det er at sammenligne dem kommer an på algoritmen. Alm.
XOR er jo f.eks. perfekt sikker, hvis nøglen har samme længde som
klartekst, men jo mere nøglen genbruges, jo nemmere er det at finde
nøglen ... grænsende til det trivielle.

Peter

---

Kent Friis wrote:
>>1) Stor datamængde - kanalerne der bære videosignalerne.
> Kortet dekrypterer ikke (eller gjorde i hvert fald ikke på D2-Mac)
> selve signalerne, men kun en den kode der skal bruges til at
> dekode signalerne. Det var en kode per to et halvt sekund, SVJH, altså
> meget mindre end data-mængden i selve video-signalet.

Modtageren dekryptere vel signalet udfra den dekrypteret kode.

>>2) Klartekst udgaven kan købes - køb et lovligt kort.
> Jeg troede egentlig at krypterings-algoritmer forhindrede at finde
> nøglen ved at sammenligne ciphertekst og klartekst - er det ikke hele
> fidusen?

Afhændigt af hvilken algoritme der benyttes.

>>3) Håndtering af fejl i modtagelsen.
> 1. Error-correction før bit-streamen når dekrypterings-delen. 2. Intet
> billede de næste to et halvt sekund, hvis error-correction'en ikke
> er nok.

Hvilket sætter krav til algoritmen.

>>4) Billig dekoder.
> Ikke nødvendig for at kommunikere med et smartcard, da der er tale om
> et standard-interface (iso-et eller andet, mener jeg).

Dekoder boksen laver så mange andre ting, menusystem, modtagelse,
dekodning af videosignal, dekomprimering af videosignal, dekodning af
nøgle, understøttelse af kort, ectetera.

---

Den Tue, 30 Aug 2005 22:40:57 +0200 skrev Christian E. Lysel:
> Kent Friis wrote:
>>>1) Stor datamængde - kanalerne der bære videosignalerne.
>> Kortet dekrypterer ikke (eller gjorde i hvert fald ikke på D2-Mac)
>> selve signalerne, men kun en den kode der skal bruges til at
>> dekode signalerne. Det var en kode per to et halvt sekund, SVJH, altså
>> meget mindre end data-mængden i selve video-signalet.
>
> Modtageren dekryptere vel signalet udfra den dekrypteret kode.

Sig hellere dekoder signalet, det er ikke hvad vi normalt forstår
ved kryptering (dette kan være ændret efter skiftet til digital TV,
jeg har ikke fulgt med i parabol-verdenen). Men ellers jo, det gør
bare ikke mængden af data der er tilgængelig for at finde krypterings-
nøglen større.

>>>2) Klartekst udgaven kan købes - køb et lovligt kort.
>> Jeg troede egentlig at krypterings-algoritmer forhindrede at finde
>> nøglen ved at sammenligne ciphertekst og klartekst - er det ikke hele
>> fidusen?
>
> Afhændigt af hvilken algoritme der benyttes.

Der er jeg så i tvivl om det var DES eller Triple-DES der blev brugt,
nutildags er det vel AES, men jeg har som sagt ikke fulgt med.

>>>3) Håndtering af fejl i modtagelsen.
>> 1. Error-correction før bit-streamen når dekrypterings-delen. 2. Intet
>> billede de næste to et halvt sekund, hvis error-correction'en ikke
>> er nok.
>
> Hvilket sætter krav til algoritmen.

Hvilke krav stiller det til algoritmen, for at få den til at virke ved
perfekt input, og ikke virke ved bit-fejl?

>>>4) Billig dekoder.
>> Ikke nødvendig for at kommunikere med et smartcard, da der er tale om
>> et standard-interface (iso-et eller andet, mener jeg).
>
> Dekoder boksen laver så mange andre ting, menusystem, modtagelse,
> dekodning af videosignal, dekomprimering af videosignal, dekodning af
> nøgle, understøttelse af kort, ectetera.

Som overhovedet ikke er nødvendigt for at knække koden på kortet.

Ja, det er nødvendigt for at bruge den til noget, men hvis man har
stjålet et smartcard til kryptering af en PC, har man nok også stjålet
PC'en hvis man gider besværet med at knække kortets sikkerhed. Og en
stjålet ("gratis") PC er endnu billigere end dekoderen.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
> Sig hellere dekoder signalet, det er ikke hvad vi normalt forstår
> ved kryptering (dette kan være ændret efter skiftet til digital TV,
> jeg har ikke fulgt med i parabol-verdenen). Men ellers jo, det gør
> bare ikke mængden af data der er tilgængelig for at finde krypterings-
> nøglen større.

Det siger jeg heller ikke, men det sætter krav til løsningen, at skulle
finde en chip der håndtere den mængde data.

> Hvilke krav stiller det til algoritmen, for at få den til at virke ved
> perfekt input, og ikke virke ved bit-fejl?

Enig, fik ikke tænkt mig om.

>>Dekoder boksen laver så mange andre ting, menusystem, modtagelse,
>>dekodning af videosignal, dekomprimering af videosignal, dekodning af
>>nøgle, understøttelse af kort, ectetera.
>
> Som overhovedet ikke er nødvendigt for at knække koden på kortet.

Men som evt. kan medføre at den valgte sikkerhed er slækket pga.
ovennævte krav.

---

Den Wed, 31 Aug 2005 16:45:32 +0200 skrev Christian E. Lysel:
> Kent Friis wrote:
>> Sig hellere dekoder signalet, det er ikke hvad vi normalt forstår
>> ved kryptering (dette kan være ændret efter skiftet til digital TV,
>> jeg har ikke fulgt med i parabol-verdenen). Men ellers jo, det gør
>> bare ikke mængden af data der er tilgængelig for at finde krypterings-
>> nøglen større.
>
> Det siger jeg heller ikke, men det sætter krav til løsningen, at skulle
> finde en chip der håndtere den mængde data.

Hvordan mener du? Hastighedsmæssigt kan jeg ikke se der skal det vilde
til at dekryptere en enkelt informationsblok (hvor meget det så er,
så meget er jeg ikke inde i det) per to et halvt sekund.

Det er jo ikke vilde mængder data der er tale om.

>> Hvilke krav stiller det til algoritmen, for at få den til at virke ved
>> perfekt input, og ikke virke ved bit-fejl?
>
> Enig, fik ikke tænkt mig om.
>
>>>Dekoder boksen laver så mange andre ting, menusystem, modtagelse,
>>>dekodning af videosignal, dekomprimering af videosignal, dekodning af
>>>nøgle, understøttelse af kort, ectetera.
>>
>> Som overhovedet ikke er nødvendigt for at knække koden på kortet.
>
> Men som evt. kan medføre at den valgte sikkerhed er slækket pga.
> ovennævte krav.

Sikkerheden i kortet bør da være uafhængig af kravene til hvad den
boks kortet stikkes ind i skal kunne. Prisen på kortet selv, ja, men
i forhold til hvad det koster at *leje* sådan et kort, er det nok
småting uanset hvad de koster.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
>>Det siger jeg heller ikke, men det sætter krav til løsningen, at skulle
>>finde en chip der håndtere den mængde data.
> Hvordan mener du? Hastighedsmæssigt kan jeg ikke se der skal det vilde

Video signalet, ikke informationsblokken.

>>Men som evt. kan medføre at den valgte sikkerhed er slækket pga.
>>ovennævte krav.
> Sikkerheden i kortet bør da være uafhængig af kravene til hvad den
> boks kortet stikkes ind i skal kunne. Prisen på kortet selv, ja, men
> i forhold til hvad det koster at *leje* sådan et kort, er det nok
> småting uanset hvad de koster.

Lejen, dækker også leje af infrastrukturen, fx drift af en eller flere
satelitter.

---

Den Thu, 01 Sep 2005 21:47:15 +0200 skrev Christian E. Lysel:
> Kent Friis wrote:
>>>Det siger jeg heller ikke, men det sætter krav til løsningen, at skulle
>>>finde en chip der håndtere den mængde data.
>> Hvordan mener du? Hastighedsmæssigt kan jeg ikke se der skal det vilde
>
> Video signalet, ikke informationsblokken.

Kortet dekrypterer *ikke* videosignalet (stadig D2-Mac, det er
muligt det er ændret på digitale signaler), men kun den række tal
der skal til at styre dekodningen. Hvis jeg husker og har forstået
det korrekt, er det blot seed'en til en pseudo-tilfældigtalsgenerator,
denne seed bliver så skiftet hver 2.5 sekunder, så det ikke hjælper
noget at gætte sig frem til den. Der er ikke tale om store mængder data.

Kortet arbejder digitalt, og ville slet ikke være i stand til at
dekode et analogt signal.

>>>Men som evt. kan medføre at den valgte sikkerhed er slækket pga.
>>>ovennævte krav.
>> Sikkerheden i kortet bør da være uafhængig af kravene til hvad den
>> boks kortet stikkes ind i skal kunne. Prisen på kortet selv, ja, men
>> i forhold til hvad det koster at *leje* sådan et kort, er det nok
>> småting uanset hvad de koster.
>
> Lejen, dækker også leje af infrastrukturen, fx drift af en eller flere
> satelitter.

Dem kan de vel tage af indtægterne fra betaling for kanalerne, som
kommer ud over lejen af kortet... (Lejen af kortet inkluderer kun
TV3, som officielt er 100% reklame-financieret).

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
> Kortet dekrypterer *ikke* videosignalet (stadig D2-Mac, det er
> muligt det er ændret på digitale signaler), men kun den række tal
> der skal til at styre dekodningen. Hvis jeg husker og har forstået
> det korrekt, er det blot seed'en til en pseudo-tilfældigtalsgenerator,
> denne seed bliver så skiftet hver 2.5 sekunder, så det ikke hjælper

Det lyder jo ikke så tungt, beregningsmæssigt.

> noget at gætte sig frem til den. Der er ikke tale om store mængder data.
>
> Kortet arbejder digitalt, og ville slet ikke være i stand til at
> dekode et analogt signal.

Når jeg skriver video signalet mener jeg i digital form...men fremgår
ikke tydeligt.

> Dem kan de vel tage af indtægterne fra betaling for kanalerne, som
> kommer ud over lejen af kortet... (Lejen af kortet inkluderer kun
> TV3, som officielt er 100% reklame-financieret).

Enig

---

Den Sat, 03 Sep 2005 11:09:43 +0200 skrev Christian E. Lysel:
> Kent Friis wrote:
>> Kortet dekrypterer *ikke* videosignalet (stadig D2-Mac, det er
>> muligt det er ændret på digitale signaler), men kun den række tal
>> der skal til at styre dekodningen. Hvis jeg husker og har forstået
>> det korrekt, er det blot seed'en til en pseudo-tilfældigtalsgenerator,
>> denne seed bliver så skiftet hver 2.5 sekunder, så det ikke hjælper
>
> Det lyder jo ikke så tungt, beregningsmæssigt.

Netop, det er det jeg forsøger at sige.

>> noget at gætte sig frem til den. Der er ikke tale om store mængder data.
>>
>> Kortet arbejder digitalt, og ville slet ikke være i stand til at
>> dekode et analogt signal.
>
> Når jeg skriver video signalet mener jeg i digital form...men fremgår
> ikke tydeligt.

For D2-Mac's vedkommende er video-signalet analogt (lyden er digital),
og det var det man brugte dengang jeg rodede med piratkort. (Men så
gik det op for mig at med den ene film der var værd at se på TV1000
om året, var det billigere at gå i biografen end at holde kortet
opdateret).

Jeg er ikke så meget inde i hvordan det virker ved digitale modtagere,
men der er noget med at kortet i sig selv ikke er nok, der skal også
et såkaldt "CAM"-modul til (som kan være indbygget i satellit-
modtageren). Dette CAM-modul er forskellig alt efter hvilken form
for kodning kanalen benytter, hvilket for mig lyder som om at systemet
virker på samme måde - kortet dekrypterer en "session key", og
CAM-modulet dekrypterer video-signalet.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

On Mon, 29 Aug 2005 20:12:18 +0200, Martin wrote:

> Findes der nogle gode måder at sikre indholdet på medarbejdernes
> bærbare, kryptering?

Jeg skrev lidt om CompuSec i news:<d8oqfo$6pn$1@dax.goth.fw> -
den er stadigvæk fin.

> Kan det styres centralt?

Næppe i gratis-udgaven (den er dog flerbruger), men check deres
andre produkter.

--
Stig

---

Martin wrote:
> Findes der nogle gode måder at sikre indholdet på medarbejdernes
> bærbare, kryptering?
>
> Jeg har hørt noget om at der er en "sikkerhedschip" i IBM'erne, men kan
> den bruges til noget fornuftingt?
>
> Kan det styres centralt?
> Evt generelle erfaringer?
>
> Mvh
> Martin

jeg havde et lignede spørgsmål oppe og vende for, maksimakt et par
måneder siden, hvor der kom en del gode indlæg, tjek den ud....