• Välkommen till ett uppdaterat Klocksnack.se

    Efter ett digert arbete är nu den största uppdateringen av Klocksnack.se någonsin klar att se dagens ljus.
    Forumet kommer nu bli ännu snabbare, mer lättanvänt och framför allt fyllt med nya funktioner.

    Vi har skapat en tråd på diskussionsdelen för feedback och tekniska frågeställningar.

    Tack för att ni är med och skapar Skandinaviens bästa klockforum!

    /Hook & Leben

Säkra klockan med blockkjedja

mega

Rolex
Well, problemet så som jag ser det är att hur du än vrider och vänder på detta så är det du försöker göra; binda en sträng till ett fysiskt objekt. Detta är möjligt ur ett relationsperspektiv, men inte möjligt sett ifrån en säkerhetssynpunkt. Om strängen på något sätt går att manipulera eller byta ut på objektet, så brister hela konceptet.

Så att bygga ett system kring det fysiska klockor, hade kanske vart möjligt med DNA-märkning och kryptografiska chip om klockorna tillverkats med det ifrån start. Men, detta innebär att inga klockor som inte tillverkas med just den processen, skulle gå att säkra. Så alla klockor som redan finns, går inte att säkra på det sättet. Det finns väl redan klocktillverkare som gör detta idag ? Hade inte breitling någon idé här kring tex. ?


"Sen hoppas man på att de fysiska datapunkterna inte ändras över tid? " , och om det gör det, ska man då nullifiera diamanten och räkna den som oäkta helt plötsligt ? Tråkigt för den som köpte den stenen. :) Om objektet också bara kan ändras på utav den som äger privata nyckeln, hur gör man då om personen förlorar sin nyckel ? Vad gör man vid dödsfall ?






En centraliserad databaslösning med checksummeverifiering. Det hade vart mycket snabbare än en blockkedja också. En blockkedja ser ut som den gör, för att den har settlementperioder där informationen sparas, vilket är nödvändigt då systemet behöver veta att alla noder är överens. Detta gör processerna kring kedjan långsamma.





Både ja, och både nej! Historiken i en blockkedja går att ändra, om 51% eller mer av nätverket är överens om ändringen. Kretsar systemet kring en centraliserad part,kan man oftast räkna med att dom har merparten utav beräkningskapaciteten i nätverket.
Well, problemet så som jag ser det är att hur du än vrider och vänder på detta så är det du försöker göra; binda en sträng till ett fysiskt objekt. Detta är möjligt ur ett relationsperspektiv, men inte möjligt sett ifrån en säkerhetssynpunkt. Om strängen på något sätt går att manipulera eller byta ut på objektet, så brister hela konceptet.

Så att bygga ett system kring det fysiska klockor, hade kanske vart möjligt med DNA-märkning och kryptografiska chip om klockorna tillverkats med det ifrån start. Men, detta innebär att inga klockor som inte tillverkas med just den processen, skulle gå att säkra. Så alla klockor som redan finns, går inte att säkra på det sättet. Det finns väl redan klocktillverkare som gör detta idag ? Hade inte breitling någon idé här kring tex. ?


"Sen hoppas man på att de fysiska datapunkterna inte ändras över tid? " , och om det gör det, ska man då nullifiera diamanten och räkna den som oäkta helt plötsligt ? Tråkigt för den som köpte den stenen. :) Om objektet också bara kan ändras på utav den som äger privata nyckeln, hur gör man då om personen förlorar sin nyckel ? Vad gör man vid dödsfall ?






En centraliserad databaslösning med checksummeverifiering. Det hade vart mycket snabbare än en blockkedja också. En blockkedja ser ut som den gör, för att den har settlementperioder där informationen sparas, vilket är nödvändigt då systemet behöver veta att alla noder är överens. Detta gör processerna kring kedjan långsamma.





Både ja, och både nej! Historiken i en blockkedja går att ändra, om 51% eller mer av nätverket är överens om ändringen. Kretsar systemet kring en centraliserad part,kan man oftast räkna med att dom har merparten utav beräkningskapaciteten i nätverket.

Det man knyter klockan med är serienumret, som är instansat i boetten samt står på ett cert.
Visst kan man ändra/förfalska det på en stulen klocka, mendet är mycket jobb, sen skall du bevisa för AD att du är nya ägaren också (kvitton?)...

Vid dödsfall måste den nya ägaren förstås presentera papper för AD från dödsbo etc som gör honom till ny ägare.

Historiken i BC går inte att ändra, oavsett 51%. Däremot kan du smyga in felaktigheter i nya transaktioner.
Har man en kopia av BC så ser man direkt att någonting har ändrats.
I min värld kommer tillverkaren, ex. Rolex att ha 100% av nätverket, så det blir i praktiken en non-issue.
Det är inte heller ett speciellt transaktionsintensivt nätverk, så jag tror inte att effektiviteten/snabbheten skulle vara ett problem.
 

twisted

Cartier
Det man knyter klockan med är serienumret, som är instansat i boetten samt står på ett cert.
Visst kan man ändra/förfalska det på en stulen klocka, mendet är mycket jobb, sen skall du bevisa för AD att du är nya ägaren också (kvitton?)...

Vid dödsfall måste den nya ägaren förstås presentera papper för AD från dödsbo etc som gör honom till ny ägare.

Historiken i BC går inte att ändra, oavsett 51%. Däremot kan du smyga in felaktigheter i nya transaktioner.
Har man en kopia av BC så ser man direkt att någonting har ändrats.
I min värld kommer tillverkaren, ex. Rolex att ha 100% av nätverket, så det blir i praktiken en non-issue.
Det är inte heller ett speciellt transaktionsintensivt nätverk, så jag tror inte att effektiviteten/snabbheten skulle vara ett problem.


Om rolex ändå skulle ha 100% av nätverket, vad är då poängen med att använda en decentraliserad publik blockkedja? Då fungerar en centraliserad databaslösning med checksummeverifiering och ett REST api för alla som vill titta i den lika bra om inte bättre, då uppgraderingar och underhållsarbete är betydligt smidigare i ett centraliserat system. Det jag är mer inne på är att man nästan alltid kan implementera en blockkedja i ett system, men det är sällan det verkligen behövs.
 

mega

Rolex
Om rolex ändå skulle ha 100% av nätverket, vad är då poängen med att använda en decentraliserad publik blockkedja? Då fungerar en centraliserad databaslösning med checksummeverifiering och ett REST api för alla som vill titta i den lika bra om inte bättre, då uppgraderingar och underhållsarbete är betydligt smidigare i ett centraliserat system. Det jag är mer inne på är att man nästan alltid kan implementera en blockkedja i ett system, men det är sällan det verkligen behövs.
Blockkedjan är inte decentraliserad, tvärtom 100% centraliserad. Men publik.
En BC är väl på sätt och vis en databas med checksummor? Eller egentligen en lång transaktionskedja med checksummor?
 

Smeden

Panerai
Friends Of KS
BC är enligt mig ett teknikval som är jädrans bra på ett par tre punkter, men man ska ha behov av samtliga punkter för att välja det som lösning. Så fort man inte är ute efter tex punkten decentraliserad makt har man i BC nackdelar som överväger fördelarna. Jag vill hävda/chansa att det är dyrare och kanske till och med svårare att hänga med i BC-säkerhetsutvecklingen än att göra löpande säkerhetsunderhåll på en "vanlig" IT-lösning likt den @twisted föreslår :)
Over and out, fridens!
 
Senast ändrad:
Topp