Tech Society 3.0

Or you can just, you know, take a bite out of a normal apple and get the same result.

Or you can just, you know, take a bite out of a normal apple and get the same result.

Can't be too difficult right? All you have to do is force the apples to grow into that shape by surrounding it with a small, shaped metal box. Similar to how they make square watermelons in Japan.

I have a number ideas for that. either there is an override kept of site in a secure location with extremely limited access to it. so if the USB key is lost, a person from the company has to come out with override, and register the new key for use with that drive.
^ that's the more secure/high level version
Otherwise, I could provide a method where the company has two copies of the key. So if one is lost, the second can be delivered. however there can only ever be two keys to every drive. No more. if the organisation loses the second and doesn't have a backup, then they lose access. that simple.

The box is designed to prevent tampering and prevent access, possibly destroying data inside of the drive is improperly accessed.

Interesting. You'd need some kind of embedded system I think, the HDD itself could not act as both a USB client (to the PC) and as a USB host (to the key). If you stuck a Rasberry Pi or something inside it, then hook it directly to the HDD, you could then control access using the USB key, which contains the passphrase file to the encrypted drive.

This wouldn't stop someone from copying the key itself though. But since the USB key is writable you could do what most keycard systems do and have a one-in, one-out system. That means if someone does duplicate the key, and then uses it, the original key gets voided and can no longer be used. Similarly if someone makes a key clone, then the original is used, the clone would be nulled instead.

It's certainly an interesting project. Is it a school/uni thing, or just something you dreamt up?

I think what S-Man was possibly alluding to was if the WAN connection was on the blink, then how could you get around that problem with a VPN connection, which traverses the same WAN.

Interesting. You'd need some kind of embedded system I think, the HDD itself could not act as both a USB client (to the PC) and as a USB host (to the key). If you stuck a Rasberry Pi or something inside it, then hook it directly to the HDD, you could then control access using the USB key, which contains the passphrase file to the encrypted drive.

This wouldn't stop someone from copying the key itself though. But since the USB key is writable you could do what most keycard systems do and have a one-in, one-out system. That means if someone does duplicate the key, and then uses it, the original key gets voided and can no longer be used. Similarly if someone makes a key clone, then the original is used, the clone would be nulled instead.

It's certainly an interesting project. Is it a school/uni thing, or just something you dreamt up?

To be perfectly honest, I have no idea. No details were given.
It might have been something to do with the DNS dying, which would explain it (but doesn't explain why the dns cache didn't help).

It was probably a campus firewall problem, then - did you check NetSight? A VPN probably wouldn't have helped with a JaNET infrastructural outage and I've been a JaNET user for years and years with very few issues relating to JaNET itself - it's epically reliable in my experience and its infrastructure is sound.

****in' makefiles, how do they work?

I swear, of all the misbegotten creations from the minds of Unix developers, makefiles and autotools rank as one of the worst. If trying to beat them into submission wasn't so tragic it would be hilarious.

It's like a variation of the 'Yo dawg' meme. Just in case one language for your application isn't enough, you get a completely different one to get your application to compile. But sometimes this is too inflexible, so we use configure files. But sometimes editing these by hand is too error-prone, so we generate configure files automatically. Hey guys, how many more abstraction layers can we get in there!? It's so much fun debugging the thousand lines of computer generated garbage! And (of course) you have to know all three layers of this mess to be prepared for other developers.

But then, they're 30 years old and they do have (some) good points. But they could be so much better...which is precisely why there are now alternatives like cmake and scons (and why other languages made their own build mechanisms). But then we all know de-facto doesn't mean good.

It was probably a campus firewall problem, then - did you check NetSight? A VPN probably wouldn't have helped with a JaNET infrastructural outage and I've been a JaNET user for years and years with very few issues relating to JaNET itself - it's epically reliable in my experience and its infrastructure is sound.

They don't give details because a) 99.9% of the student population don't understand it, so why bother and b) the 0.1% who do it's none of their business and they should stick to their pointless Java assignments doing things that don't need doing in a way you wouldn't normally do it. These University sysadmins don't like CompSci students poking their noses in and they certainly hated us Security and Ethical Hacking crew for the **** we pulled.

But, again, what do I know?

Interesting. You'd need some kind of embedded system I think, the HDD itself could not act as both a USB client (to the PC) and as a USB host (to the key). If you stuck a Rasberry Pi or something inside it, then hook it directly to the HDD, you could then control access using the USB key, which contains the passphrase file to the encrypted drive.

This wouldn't stop someone from copying the key itself though. But since the USB key is writable you could do what most keycard systems do and have a one-in, one-out system. That means if someone does duplicate the key, and then uses it, the original key gets voided and can no longer be used. Similarly if someone makes a key clone, then the original is used, the clone would be nulled instead.

It's certainly an interesting project. Is it a school/uni thing, or just something you dreamt up?

So I spoke to a guy in year two of Information Security here, who's putting alot of info into this project for me. He suggested I work on developing the idea then implement it through my project management/dissertation in years 2 and 3.
However I don't like the idea of putting something like this into my project management as I know it is not something I could develop on my own. infact, after drawing up plans and designs, I realised I'm going to need an encryption specialist, an engineer and possibly a damned good coder...

As for the USB keys. we're thinking of implementing a writeblocker so nothing can be written to the keys after the first time. one, which the user keeps hold of, has standard access and modification rights, whereas the other has ROOT rights for that box only and is stored offsite in a secure location.

This wouldn't stop someone from copying the key itself though. But since the USB key is writable you could do what most keycard systems do and have a one-in, one-out system. That means if someone does duplicate the key, and then uses it, the original key gets voided and can no longer be used. Similarly if someone makes a key clone, then the original is used, the clone would be nulled instead.

So I spoke to a guy in year two of Information Security here, who's putting alot of info into this project for me. He suggested I work on developing the idea then implement it through my project management/dissertation in years 2 and 3.
However I don't like the idea of putting something like this into my project management as I know it is not something I could develop on my own. infact, after drawing up plans and designs, I realised I'm going to need an encryption specialist, an engineer and possibly a damned good coder...

As for the USB keys. we're thinking of implementing a writeblocker so nothing can be written to the keys after the first time. one, which the user keeps hold of, has standard access and modification rights, whereas the other has ROOT rights for that box only and is stored offsite in a secure location.

I think I've missed a critical post here, I feel lost.

I don't understand. Are you talking about a simple USB drive with the key written to the storage?
Why would you not create USB device with specialised hardware (thereby preventing copying) to provide (say) a complete challenge-auth whatsit with a delay of 5 mins to prevent brute forcing (for example)?


Similar to above, why limit yourself to a USB drive? Of course, I'm not privy to all the info you have at hand, so take my suggestion with a pinch of salt, but why not contain an entire (to quote an earlier post of yours) "authentication system" within the hardware of the USB device? But that does have downsides...

There were two main things I learnt in security courses
1) Security is hard.
2) Hardware security is really hard.

To quote one guy - "We teach you security so you know you can't go out there and build a secure system. However, we can sell you a product that does allow you to do this. It's called a PhD."
But then, this was a general CS course.

Good luck with it, it sounds interesting.

Dez is right; TrueCrypt can achieve this already.

You can create an encrypted volume on a USB stick that requires a password and an encryption key to access it. The encryption key is just a text file that contains a private random key, essentially creating a two-factor authentication for the file. You could store that key on another USB stick and avoid the need for additional hardware.

Yeah if you go back to a page or so, I've tried to outline details.
the authentication system on the USB device is what we are thinking, but we want to have it verified on the side of the actually storage device, sort of as an extra layer.


The thing is, we don't want this to use public software, we want to have full control over everything from the encryption, to the security.
But the idea of putting in an encrypted volume storing the key is interesting..

The problem is, strong encryption algorithms are all public. Unless you're thinking of a new encryption method, you're going to have to use a public algorithm. Proprietary encryption software/hardware is arguably no more secure than open source equivalents, as it's not the software or hardware that provides the strength of the encryption; it's the algorithm that provides the strength.

Oh?

There were two main things I learnt in security courses
1) Security is hard.
2) Hardware security is really hard.

To quote one guy - "We teach you security so you know you can't go out there and build a secure system. However, we can sell you a product that does allow you to do this. It's called a PhD."
But then, this was a general CS course.

Oh I don't disagree, but I just want alternatives if possible, especially if I can find a system that can be embedded within another program/OS. Which i don't know if Truecrypt can be?

I think my spacebar is slowly dying. It feels different, sticks a bit and doesn't always respond - probably Starcraft rage



We had our own heavily firewalled network with only port 80 open. Even then, all traffic going to core University systems (WebCT, Webmail etc.) was dropped for security reasons so we needed to use our own laptops and the campus WiFi for that.

The Cisco ASA (or maybe it was a PIX - can't quite remember) was set up to stop all traffic out of the NATted network in the event of serious security alerts against University systems e.g. port scans against central University IT infrastructure. Eventually they rolled out a new IDS policy to lock out individual workstations (we didn't have user accounts - all machines were restorable boxes running as Administrator so we could do what we wanted as long as we restored the base image afterwards) rather than the entire NAT range but it was occasionally fun to lock out the entire lab for lulz.

In short, they didn't like us because we were a lot of extra work and were the exact type of people pre-programmed to make their lives difficult. Someone else also apparently found a 0day in the main portal software.



This is nonsense and whoever told you this should jump in front of a train. You also didn't learn very much.



Careful with rolling your own encryption schemes, algorithms or systems. There's a reason why some of the brightest minds in the world work on that sort of stuff and how it goes through brutal peer review. TrueCrypt is the best I've seen and you can encrypt whole physical volumes with it. However, if you're truly wanting to break away from what has already been used, you're going to have to seriously think outside of the box.

I'm beginning to think that your very own hardware solution is probably the key (hurr hurr hurr) to this conundrum of Thor+Ultralisk proportions. I can't currently think of anything which would work straight out of the box, or indeed be adapted straight out of said box, so it's a hugely complex problem and one I can't really go into right now because it requires a very, very serious amount of thought.

Yeah if you go back to a page or so, I've tried to outline details.
the authentication system on the USB device is what we are thinking, but we want to have it verified on the side of the actually storage device, sort of as an extra layer.