I have a lot of concerns with this project, so let me brutally honest here. When it comes to cryptography the most dangerous thing is for someone who doesn't know about it to try implementing it. And honestly, you don't know about it. I say that because of your lack of caring about what encryption algorithm is used. I also don't think that you really know the computational resources required for public/private key encryption.
Even if you chose the correct encryption algorithm, and implemented it perfectly, that doesn't mean your device is secure. Most encryption security breaches are not from someone doing a brute force attack on the key, but from something else that is much easier and has nothing to do with the algorithm used. For example, if you encrypt the ethernet packet headers then you'll have better security, but you won't be able to send this data through a standard ethernet switch and/or layer 3 router. If you don't encrypt the headers then you're opening yourself up to a form of analysis and attack that could give someone information even without breaking the encryption.
A book that I highly recommend is Applied Cryptography. It talks about lots of issues with cryptography, and also goes through a lots of algorithms. It is a little dated in that it doesn't cover AES, but it does talk about many hash algorithms, DES, and public/private key encryption.
Ok, now on to your real question: Can it be done for $35/each? Absolutely! Can YOU do it for $35/each? Well, I can't answer that. You simply didn't give us enough information. For starters, is this a hobby project or something that will be made in volume? What is your case/chassis going to be? How is this going to be controlled, via LCD and buttons?
If you are only building two of these things then it is going to be very hard to get the price down to $35. It would actually be hard to get the price down below $250. But even in volumes of around 2K/year I would estimate that the PCB+parts would be in the $30-35 range and that doesn't factor in the cost of labor, a chassis, or an AC/DC power supply. Also, there might be cheaper ways to do this that don't use an FPGA.
CAN sounds the most applicable in this case. The distances inside a house can be handled by CAN at 500 kbits/s, which sounds like plenty of bandwidth for your needs. The last node can be a off the shelf USB to CAN interface. That allows software in the computer to send CAN messages and see all the messages on the bus. The rest is software if you want to present this to the outside world as a TCP server or something.
CAN is the only communications means you mentioned that is actually a bus, except for rolling your own with I/O lines. All the others are point to point, including ethernet. Ethernet can be made to logically look like a bus with switches, but individual connections are still point to point and getting the logical bus topology will be expensive. The firmware overhead on each processor is also considerably more than CAN.
The nice part about CAN is that the lowest few protocol layers are handled in the hardware. For example, multiple nodes can try to transmit at the same time, but the hardware takes care of detecting and dealing with collisions. The hardware takes care of sending and receiving whole packets, including CRC checksum generation and validation.
Your reasons for avoiding PICs don't make any sense. There are many designs for programmers out there for building your own. One is my LProg, with the schematic available from the bottom of that page. However, building your own won't be cost effective unless you value your time at pennies/hour. It's also about more than just the programmer. You'll need something that aids with debugging. The Microchip PicKit 2 or 3 are very low cost programmers and debuggers. Although I have no personal experience with them, I hear of others using them routinely.
Added:
I see some recommendations for RS-485, but that is not a good idea compared to CAN. RS-485 is a electrical-only standard. It is a differential bus, so does allow for multiple nodes and has good noise immunity. However, CAN has all that too, plus a lot more. CAN is also usually implemented as a differential bus. Some argue that RS-485 is simple to interface to electrically. This is true, but so is CAN. Either way a single chip does it. In the case of CAN, the MCP2551 is a good example.
So CAN and RS-485 have pretty much the same advantages electrically. The big advantage of CAN is above that layer. With RS-485 there is nothing above that layer. You are on your own. It is possible to design a protocol that deals with bus arbitration, packet verification, timeouts, retries, etc, but to actually get this right is a lot more tricky than most people realize.
The CAN protocol defines packets, checksums, collision handling, retries, etc. Not only is it already there and thought out and tested, but the really big advantage is that it is implemented directly in silicon on many microcontrollers. The firmware interfaces to the CAN peripheral at the level of sending and receiving packets. For sending, the hardware does the colllision detection, backoff, retry, and CRC checksum generation. For receiving, it does the packet detection, clock skew adjusting, and CRC checksum validation. Yes the CAN peripheral will take more firmware to drive than a UART such as is often used with RS-485, but it takes a lot less code overall since the silicon handles so much of the low level protocol details.
In short, RS-485 is from a bygone era and makes little sense for new systems today. The main issue seems to be people who used RS-485 in the past clinging to it and thinking CAN is "complicated" somehow. The low levels of CAN are complicated, but so is any competent RS-485 implementation. Note that several well known protocols based on RS-485 have been replaced by newer versions based on CAN. NMEA2000 is one example of such a newer CAN-based standard. There is another automotive standard J-J1708 (based on RS-485) that is pretty much obsolete now with the CAN-based OBD-II and J-1939.
Best Answer
As Marcus suggested, this is where the locally administered MAC addresses come handy. Here is the structure of a MAC address (taken from Wikipedia):
So, set b0 of the first byte to 0 (unicast) and b1 of the first byte to 1, and then you're free to set the other bits as you wish.
However, this requires that you can ensure the following thing: this port should never be connected to a network where there might potentially be other nodes with locally administered MAC addresses.
But equipments with locally administered MAC addresses are not supposed to be found on the market. If the only equipment that can potentially be connected to this port is a regular laptop, or even a whole newtork containing only regular switches/routers and computers, there is no such risk.
Now, there are two strategies: either you decide on a single MAC address and assign it to all your devices (they will all have the same address), or you define a scheme with a fixed and a variable part (the variable part can be taken from the serial number of the device if there is one available somewhere), so that each device has a unique (locally administered) MAC.
The single MAC address scheme is only possible is you can ensure that:
Regarding your concern of potential MAC address filters set by the IT: this isn't likely. MAC address filters are typically set on a network equipment (wifi access point, network switch, ...), and are set so that only registered nodes can connect to the network. If this is the case, you'll have a problem anyway, because your device won't be registered whether it has a regular OUI-assigned address or a locally administered one. I have never seen a MAC address filter set on a computer station, even in totally paranoiac IT environments.
As a conclusion, I think having a locally administered address in this case likely won't lead to a problem. However, problems are more likely to arise if you assign the same address to all your devices. I'd rather use unique addresses per device if it is achievable.