[spoilers]What happens when Shannon Foraker meets...

phillies wrote:There is no flash on B. B has a set of non-writeable large ROM memories, which can write from the large ROM into the instruction core, and which are the only things that can write into the instruction core. Some of the old Commodore computers used part of this scheme. To change software coding, you have to install new hardware.

And in "Reflections on Trusting Trust" Thompson describes how the compiler used to build the OS installs a backdoor in the system authentication system every time you modify it. So that doesn't help.

And if you have a hardcoded system then your authentication keys are part of the hardware. Which means that a) you can't have them if they get exposed, and b) implies that every system has exactly the same credentials.

kzt wrote:

phillies wrote:There is no flash on B. B has a set of non-writeable large ROM memories, which can write from the large ROM into the instruction core, and which are the only things that can write into the instruction core. Some of the old Commodore computers used part of this scheme. To change software coding, you have to install new hardware.

And in "Reflections on Trusting Trust" Thompson describes how the compiler used to build the OS installs a backdoor in the system authentication system every time you modify it. So that doesn't help.

Precisely. This is why the toolset used to build a system has to be at the same or higher validation level as the system it's building.

One of the advertised advantages of open source rather than closed source tools is that people can inspect the code to find this kind of malware. It's also why they advertise cryptographic checksums out of band, and a cautious user checks that he got the right download. A really cautious user checks that the advertised checksum hasn't suddenly changed.

kzt wrote:And if you have a hardcoded system then your authentication keys are part of the hardware. Which means that a) you can't have them if they get exposed, and b) implies that every system has exactly the same credentials.

Not with modern manufacturing which can put unique serial numbers right into the chip during manufacturing. You also have EERom, which is a write-once system.

As a side note, Commodore didn't use ROM because it was more secure, they used it because flash memory didn't exist at the time, at least in any form that was usable as BIOS.

JohnRoth wrote:Precisely. This is why the toolset used to build a system has to be at the same or higher validation level as the system it's building.

One of the advertised advantages of open source rather than closed source tools is that people can inspect the code to find this kind of malware. It's also why they advertise cryptographic checksums out of band, and a cautious user checks that he got the right download. A really cautious user checks that the advertised checksum hasn't suddenly changed.

The problem with that against Thompson's attack is that that the trapdoor never appeared in the source code. You could study the freely available source code all you wanted. It was inserted by the compiler in the object. You had to reverse the object code to find it, and these sorts of trap doors are not going to be huge and easily noticed by casual observers. They are going to be small and very difficult to find by expert observers.

To avoid it you would have to have rebuilt the compiler from source without using an existing compiler and then rebuilt the entire OS and then done the checksum verification.

Step one of security: Don't hire bad people.

JohnRoth wrote:
It's certainly true that someone has to have the ability to tell the fire control system that a particular ship is friendly, or the opposite, but I'd think that would be the responsibility of the captain or the Officer of the Watch. The tac officer would only have that during the middle of a fight.

This is only one quote in your argument, but the difference in your position and mine is that all of this stuff is separated in your view, requiring multiple people to agree in order for the weapons to fire.

In my view, there is a hierarchy of people who can give the command to fire, and higher authority locks out lower authority. The only time lower authority gets control is when authorized explicitly (firing on local control for training perhaps) or because the local system no longer can communicate with higher authority (battle damage).

We see this over and over in the text. To pick one example, at 1st Hancock they describe how a missile slips through the tacnet's fire plan to target one of the smaller screening ships, and the tacnet releases the screening ship to actually defend itself (instead of the fleet as a whole). The command to change fire plan is given too late and the ship dies.

One override that is at a lower level is it seems like captains have the ability to take the entire ship out of the tacnet independently. This is how Young fled at Hancock and at 4th Yeltsin we see the BB's doing this when it appears the defensive fire solution for the wall of battle isn't going to get the job done (this is probably a dumb panic decision, but they had the privs to do it)

At Hancock, everyone executed the fire plan sent by the flag. The consequences of somebody not doing that is shown by Young.

You want a flexible, simple way of allowing fire control to happen, because a battle can spring on you in literally seconds. Somebody comes out of stealth and fires on you, or somebody hypers in. We've seen the Bellepheron DN get a fire plan together in less than a minute from a cold start, on an old-style, manpower intensive ship not at battle stations, using the temporary authority of an ensign and, presumably, a compentent tac officer backing the newbie in the command chair.

You get BETTER fire control execution with everyone at battlestations and everyone engaged in the process. But the fleet can execute a fire control plan entirely from computer control, triggered by a single person, while most of the staff are still running out of the shower, or their bedrooms or whatever to their battle stations.

Who writes those canned fire control programs that the fleet will use in such an emergency? The fleet tac officer.

If the fleet tac officer decides to blow up the fleet simultaneously, whatever lower level overrides exist (like commander taking his ship out of the tacnet) won't be able to be executed in time.

Ravenschild wrote:Wouldnt a bigger question be what happens when Shannon and Scotty see eachother again?Cause it seems from his tech witch comment in earlier books there might have been some intrest there...especially with the peace being made that intrest is now possible to be followed up on. That courtship might be as amusing a Harkness and Babcocks lol.

Cap'n Roderick wrote:...Admiral Hemphill?

One of the things I've always enjoyed in this whole series is the interesting counter-strategies and technologies employed by both Haven and Manticore throughout the various wars. Especially the cunning little tactical doctrines I, for one, would never have thought of in the same situation, and these are in many cases originated by Admiral Foraker, as ways to get around the technological advantage of the SKM.

So, as a bit of wish-listing, what do all you Honorverse tech-heads think Shannon might be able to come up with to give the League's thousand-waller fleets a bowel problem if/when she gets some playtime with BuWeaps and the cutting edge of Manticoran technology?

This may be partially wishful thinking, but I agree that there may be something there. Even if there isn't yet, it seems like a much more likely scenario than Foraker/Hemphill. The Harkness/Babcock analogy may even be somewhat applicable.

Also, while watching them stumble through courtship might be entertaining, I can think of a potentially far more entertaining scenario.

Scotty and Foraker have been working together at Bolthole (Don't see Hemphill spending mush time there, don't see Foraker spending much time away) and getting along fine. One evening they sit down for an informal project meeting, and like many of Honor's informal meetings, alcohol is available. The next morning they wake up to find themselves very married, and decide to just go with it. I suspect Harkness would be amused.

Can't you just see the looks on the faces of the poor ignorant major players visiting Bolthole when Foraker finishes her greeting with "...And I belive you know my husband Commadore Scotty Tremain."




As for the results of Haven/Mantie/Grayson tech collaboration, I would personally suspect that it will be based at Bolthole, the only major intact and fairly secure R&D base in the GA, and will therefore be under the direct command of Foraker, with Hemphill cooperating separately from Manticore. I suspect that a lot of the R&D for a while will be focused on bootstrapping the RHN up to MA standards, although I could see new builds that significantly improve on current MA equipment. For instance, if super tac witch Foraker, fighter jockey Scotty Tremain and the Katana design team put together they would be almost certain to come up with something that would obsolesce the Katana. In that general vein of thought, given the R&D command experience Scotty already has and the loss of most of the high level R&D officers on Weyland, it seems possible that Scotty could get promoted to command the Mantie R&D detachment at Bolthole, and even if he isn't he could easily fill a lesser command role, similarly to Alice Truman during LAC creation.

Honestly, even with the GA's R&D Dream Team conspiring I don't see any truly unique innovations turning up anytime soon. What I do see coming is a bunch of radical redesigns of existing tech like we saw with the rise of the GSN. In all probability we will see solid advances in everything from ships to Apollo to Keyhole/Ghost Rider simply because Foraker tore it apart and went huh and proceeded to rebuild it with parts from two other things and some seemingly anachronistic junk.

kzt wrote:

phillies wrote:There is no flash on B. B has a set of non-writeable large ROM memories, which can write from the large ROM into the instruction core, and which are the only things that can write into the instruction core. Some of the old Commodore computers used part of this scheme. To change software coding, you have to install new hardware.

And in "Reflections on Trusting Trust" Thompson describes how the compiler used to build the OS installs a backdoor in the system authentication system every time you modify it. So that doesn't help.

And if you have a hardcoded system then your authentication keys are part of the hardware. Which means that a) you can't have them if they get exposed, and b) implies that every system has exactly the same credentials.

Before you take that at face value, you might want to read Bruce Schneier's rebuttal: http://www.schneier.com/blog/archives/2 ... _trus.html

Unlike Ken Thompson, who is indeed one of the grand old men who gave us the C language, Unix, Plan 9 from Bell Labs and now the Go language from Google, Bruce is a real security expert.

JohnRoth wrote:Before you take that at face value, you might want to read Bruce Schneier's rebuttal: http://www.schneier.com/blog/archives/2 ... _trus.html

Unlike Ken Thompson, who is indeed one of the grand old men who gave us the C language, Unix, Plan 9 from Bell Labs and now the Go language from Google, Bruce is a real security expert.

There are two problems that this raises. The first is that you don't typically have multiple completely separate public teams developing full sets of software for your extremely secure, highly classified system that produces the extremely sensitive and highly classified hardware modules that you use.

The second is this comment:

So, we've verified the compiler. Now we need to verify the linker and the loader, to make sure they're not adding their own little bits. And the filesystem drivers, too.

Next comes the microcode in the processors. Makes a good argument for RISC, no?

What about the firmware in the disk interfaces? The BIOS or equivalent?

kzt wrote:

JohnRoth wrote:Before you take that at face value, you might want to read Bruce Schneier's rebuttal: http://www.schneier.com/blog/archives/2 ... _trus.html

Unlike Ken Thompson, who is indeed one of the grand old men who gave us the C language, Unix, Plan 9 from Bell Labs and now the Go language from Google, Bruce is a real security expert.

There are two problems that this raises. The first is that you don't typically have multiple completely separate public teams developing full sets of software for your extremely secure, highly classified system that produces the extremely sensitive and highly classified hardware modules that you use.

The second is this comment:

So, we've verified the compiler. Now we need to verify the linker and the loader, to make sure they're not adding their own little bits. And the filesystem drivers, too.

Next comes the microcode in the processors. Makes a good argument for RISC, no?

What about the firmware in the disk interfaces? The BIOS or equivalent?

Yes. No one ever said building real systems was easy.

Foraker should and her production setup people should come to Manticore with the fabrication units that are going to build the fabrication units that will rebuild Manty cutting edge tech.

As the Manties program the Haven fabricators to bulid the fabricators that can build Manty tech, the Haven folks are given the same programs to send home. Once Manty quality fabricators are built, as they are put to work fabricating Manty tech, Haven gets those programs as well. The lines on who developes and builds Manty tech are a bit blurred. Contractors seem to have some role. Privately own tech would require Haven to buy a license from the owner.

With Foraker there (and hopefully some Graysons), there will be heard, on repeated ocassions, comments such as, "That is a really nice way to do it. But, we can make more faster if we do it this way, and it will do serve just about as well."

Only "trusted people" should be in a physical position to access ship's systems should, or you have a hell of a problem to begin with.

The greater concern should be making ship's systems accessible to the people that are trying to make them run after taking battle damage. Are you going to lock out the people doing damage control because the guy with the supersecret authentication method is dead? solberg/kzt security should be fine for ship's systems.

Tacnet's should have JohnRoth like systems to be sure that the commands are coming from a ship legitimately in the net. But, the tac people running the tacnet should only have to go through kzt/solberg security to get their commands out over the net.

There was a comment, I believe by JohnRoth, that ship in command of the tacnet would not need access to control the sensors of other ships. If I understand correctly, the ship running the tacnet for an AESA equipped Aegis battle group directs and redirects the beams of the other ships in the tacnet. With AESA equipped ships, while there is probably a periodic/cyclic general search by each ship (hopefully), much of each ship's scan is directed by the controlling ship. I am not sure where they are with it, but emissions from two or more ships can at least theorectically be combined to form composite beams.

Hemphill's R&D folks and the spooks who drafted Cardones in With One Stone should be using the kind of security that JohnRoth advocates.