• Google
    This Blog Web

October 2011

Sun Mon Tue Wed Thu Fri Sat
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          

RSS Feed

Bookmark and Share

Email Feed



  • Powered by FeedBlitz

« Who Killed the Electric Car? | Main | Large Engineering Projects »

October 17, 2006

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

Hal

How about if your nanofactory creates a little insect-sized robot. And it crawls around until it finds another nanofactory. Then it crawls inside and reprograms it to make a bunch more little insect-sized robots! Then you're in trouble.

Substitute virus-sized robot if you really want to worry.

Tom Mazanec

I doubt a virus sized robot could be made that complicated and sophisticated. But a bacterium, certainly a protozoan, could do the trick.

Greg

>I'm sure I'm only scratching the surface here, and that far more insidious and hard-to-root-out forms of nanospam are on the horizon.
It seems that every digital technology capable of displaying a message and hooked to a network eventually becomes the target of spam. It's highly likely that nanofactories will be online, along with everything else in one's house or community, for reasons of hardware updates and design transfers; those readers old enough to remember floppy disks will know that malware can travel via sneakernet and disk quite easily, too, so being unplugged is not the same as being offline<

I think a distinction you are missing here is that of "push" versus "pull". The nature of e-mail and faxes militates against your being able to forbid all communication that you did not initiate. This leaves you vulnerable to spam which, as you mention, costs the spammer little to propagate in massive amounts. Nanofactories, OTOH, are inherently "pull" technologies where you would likely initiate the download of new fabrication software. This, I argue is not like getting an e-mail from someone so much as going, say, to Mozilla.com or Opera.com to download a browser (I haven't noticed any plague of spam browsers about).

I will stipulate that this still leaves the possibility of someone hacking the site that you visit and corrupting the software you download with malware. But with suitable caution in whom you trust to provide your software this should not be a problem. Note too that there is little preventing one from having several separate standalone nanofactories, perhaps one for each software source. I emphasize standalone because in a future where there is a problem with downloading potentially corrupted software, there is no real compelling reason to have the nanofactories networked- if you _really_ need more than one nanofactory working on whatever it is that you are making, simply replicate the factory that contains the software for the item you want to make. In addition to this, it should be good design practice for every nanofactory to come with a hardware "kill-switch" which purges the current production run overriding any software instructions to the contrary. I am sure malevolent hackers, and later script kiddies, will produce the nanofactory equivalent of malware in the future but I have just as much confidence that this will be little more than an annoyance, and an avoidable one at that.

As for robots (whether insect, bacterium, or even virus sized) there are at least a couple of methods of dealing with them that I can think of off the top of my head. The first is a nano-immune system which, since it is on your own home turf ought to have a massive advantage in terms of numbers resources and the like. Even if the bad-bots evade your hard kill, the nanofactory's control mechanism can be made resistant against corruption by using an encrypted instruction stream.

Tom Craver

It's a matter of the scale of the risk.

Network connected nanofactories would potentially be subject to high speed remote manipulation of communication protocols or application software, to inject malware.

An offline nanofactory would normally require a human intermediary, and any data transferred can be scanned for malware while it is just an inactive copy. Invasive malbots could get around that - but again, we're talking many orders of magnitude greater difficulty.

Another useful approach is to create a gateway that all nanofactory instructions must pass through in order to execute correctly.

Make every nanofactory use a different binary encoding of machine instructions, so that any code coming into the nanofactory must first be translated from generic instructions to machine specific instructions.

So any software attack either must be in the local machine's unique binary format (requiring prior knowledge of the attacked machine and so limiting the spread of "worm" type attacks) or must come in via the translation gateway, where security efforts can be focused (verify the gateway code is free of exploitable bugs, simulate the results of any instructions brought in via the translation gate before letting them run the nanofactory, etc).

This approach could also be used in conventional processors, by the way.

Greg

>>Make every nanofactory use a different binary encoding of machine instructions, so that any code coming into the nanofactory must first be translated from generic instructions to machine specific instructions.<<

I think this is equivalent to my suggestion that the instruction stream be encrypted (implicit in which is the assumption that each machine has a different key to decrypt the stream). If this is so, I think we have come to a consensus on some commonsense methods of averting that nightmare.

Chris Phoenix, CRN

I like the idea of every nanofactory having its own secret key so that designs can only be downloaded from servers that know how to encrypt them properly.

One possible problem is that public-key crypto might be breakable by quantum computers--which might be easier to build with nanofactories.

Another possible problem is that the approach is only as strong as the trusted server. If someone steals the database, then your protection is broken. (In the case of physical devices physically accessing the nanofactory without knowing its online identity, you might still have some protection.)

Greg talks about "suitable caution." Hah. You know those encrypted zip file viruses? People have to open/unzip the attachment, by typing in a password (supplied in the email) and then run the executable... Given that people are that clueless (as shown by the spread of this type of virus), we simply can't count on any level of caution whatsoever.

Chris

Greg

>>Greg talks about "suitable caution." Hah. You know those encrypted zip file viruses? People have to open/unzip the attachment, by typing in a password (supplied in the email) and then run the executable... Given that people are that clueless (as shown by the spread of this type of virus), we simply can't count on any level of caution whatsoever.<<

I will readily agree that there is a limit to the degree of protection that can be supplied externally. If someone is going to visit www.scriptkiddie.com to download the fab instructions for their new personal spacecraft then all I can say is: "think of it as evolution in action". If we can arrange things so that, provided you are not unintentionally complicit in the compromise of your nanofactory, you will be able to maintain a site free of malware then we will have done a good job by my reckoning.

Hal

Supose you have a nanofactory and it makes a human-sized robot. It could use an adamantium skeleton but be surrounded by LIVING HUMAN TISSUE so it passes as human. It would come out of the nanofactory in a crouching, fetal position so it fits the output stage and then slowly stand up, naked, before it goes out to steal some clothes.

Then it goes to other nanofactories and extrudes a long spike from its finger (I forgot to mention it's made of shape-changing metal) to poke into the owner's brain and download the password to the machine. Then it reprograms it to make other humanoid robots.

NOW you're in trouble, for sure.

Let's see, at what point did I cross the line into science fiction? I have a hunch it was when I wrote, "Suppose you have a nanofactory..."

Greg

>>Let's see, at what point did I cross the line into science fiction? I have a hunch it was when I wrote, "Suppose you have a nanofactory..."<<

I find it amusing how "science fiction" is so often used in a dismissive fashion when there are all sorts of examples of things which are part of our present day world which were first depicted in science fiction: from submarines circumnavigating the world under water to tank warfare to communication satellites. Surely, what we must conclude is that being "science fiction" merely means that something has not yet happened, not that it can't.

In fact, since many of the people who actually implement the future often read and watch science fiction, I would suggest that being widely depicted such stories makes something *more* likely to come about. I suspect that the fact that the cell phone that I carry bears a close resemblance to the communicators in Star Trek is more than a matter of coincidence.

As to your mishmash of elements of the various "Terminator" movies, at most that speaks to how plausible those movies are though all you really did along those lines is say, in effect, "this is really bizarre". That, I would add, is not a particularly strong line of argument in trying to demonstrate that something is impossible. The nanofactory, which was not part of any of the "Terminator" movies, you just bundle in, presumably in hopes of getting something akin to guilt by association. Any number of arguments have been made as to why nanofactories and their products will not happen (there are a lot fewer still being made now), "that sounds like science fiction" was never a valid argument

The comments to this entry are closed.