/tech/ - Technology

101010

Posting mode: Reply

Check to confirm you're not a robot
Name
Email
Subject
Comment
Password
Drawing x size canvas
File(s)

Remember to follow the rules

Max file size: 350.00 MB

Max files: 5

Max message length: 4096

Manage Board | Moderate Thread

Return | Catalog | Bottom

Expand All Images


Requirements for Secure Clock Synchronization Anonymous 10/20/2017 (Fri) 04:12:22 [Preview] No. 11578
https://arxiv.org/abs/1710.05798

This paper establishes a fundamental theory of secure clock synchronization. Accurate clock synchronization is the backbone of systems managing power distribution, financial transactions, telecommunication operations, database services, etc. Some clock synchronization (time transfer) systems, such as the Global Navigation Satellite Systems (GNSS), are based on one-way communication from a master to a slave clock. Others, such as the Network Transport Protocol (NTP), and the IEEE 1588 Precision Time Protocol (PTP), involve two-way communication between the master and slave. This paper shows that all one-way time transfer protocols are vulnerable to replay attacks that can potentially compromise timing information. A set of conditions for secure two-way clock synchronization is proposed and proved to be necessary and sufficient. It is shown that IEEE 1588 PTP, although a two-way synchronization protocol, is not compliant with these conditions, and is therefore insecure. Requirements for secure IEEE 1588 PTP are proposed, and a second example protocol is offered to illustrate the range of compliant systems.


Anonymous 10/20/2017 (Fri) 16:22:07 [Preview] No. 11579 del
>NTP
Not secure at all. In the age of ipv6 networks it would become even worse, see how Shodan discovered vulnerable iot devices with rogue ntp servers. And with current state of TLS, you trust certificate authorities on keeping your traffic encrypted, 2 third parties involved already.
>GNSS
Better, but do not expose full positioning shell to the system, i.e. like how it is done in smartphones. Only get time signal. Extra points if you find actual military device that accepts encrypted and signed satellite signal.
Finally, add a few terrestrial radio synchronization receivers for maximum failproof. General rule of thumb for computers would be to keep real-time clock running and if the synchronization offset is too big, then something is happening and they should keep the old time setting.


Anonymous 10/20/2017 (Fri) 18:34:23 [Preview] No. 11580 del
this stupid and known. If you need ultra time synch, you buy several atomic clocks. WoT doesn't really cut it.


Anonymous 10/20/2017 (Fri) 20:30:47 [Preview] No. 11581 del
>>11579
>>11580
It's clear neither of you read the article, or didn't understand any of it if you did read it.

If you don't want to sound stupid in the future, refrain from making inane comments based on a cursory reading of the abstract.

Thank you both for your low-quality contributions to the board!


Anonymous 10/21/2017 (Sat) 08:22:22 [Preview] No. 11584 del
>>11579
Fuck the PKI, just use OpenSSL and stunnel to encrypt non-web shit.


Anonymous 10/21/2017 (Sat) 09:19:26 [Preview] No. 11585 del
>>11581
It's clear we don't need to, the proposal doesn't provide one speck of code or mitigations for other forms of attack across the net. If I required extreme time sensitive synchronization, I'd buy clocks, and synchronize them wherever we'd need them. We wouldn't even need the net&cables.

But calling someone something when they aren't interested it's just easier than dismissal.


Anonymous 10/21/2017 (Sat) 09:33:26 [Preview] No. 11586 del
>>11584
How would using a known buggy insecure clusterfuck like OpenSSL be any better?


Anonymous 10/21/2017 (Sat) 09:35:43 [Preview] No. 11587 del
>>11586
m8, I think that was the bait, and you figuratively took it


Anonymous 10/21/2017 (Sat) 16:29:52 [Preview] No. 11588 del
>>11585
>the proposal doesn't provide one speck of code or mitigations for other forms of attack across the net.
Apparently I gave you too much credit when I assumed you had at least read the abstract. I guess you didn't even do that. Or couldn't, because of your poor English.

Once again, you're crying about something you're apparently incapable of understanding. You're fucking worthless.


Anonymous 10/30/2017 (Mon) 14:02:06 [Preview] No. 11626 del
>>11581
Like reading an inane "paper" some pajeet scientist et al wrote up in latex is any better.


Anonymous 10/30/2017 (Mon) 14:54:02 [Preview] No. 11627 del
All I know is I haven't touched my personal clocks in fifteen years to adjust for daylight saving time, or any other reason.

And I haven't worn a watch for even longer.

To this day I still run across systems and organizations that are helpless without a highly payed technician onsite to adjust for DST, actively babysit routine time-clock synchronizations, etc.

The underlying (in)security aspects are important too but—man oh man—people still can't embrace the basics.



Top | Return | Catalog | Post a reply