An interviewer doesn't necessarily know the nature of the work that you have done. All of my work has been in the defense and intelligence industries, where most of what I've touched has been some combination of proprietary and covered by an non-disclosure agreement, ITAR controlled, or restricted or classified in some way. Because of this, I can't get into specifics - I don't have any code, can't show them code, and can't get into any details that I have. However, I'm very comfortable talking about the tools, technologies, and types of problems that I've solved, outlining how they were presented to me and what I did to reach a solution.
Mentioning specific tools and technologies is a very good thing. This helps your potential employer know about what kinds of experiences you've had. Maybe they use some of the same tools and platforms, and would like to hire someone with your experience in using them. Neglecting your experiences and knowledge is simply shooting yourself in the foot in an interview.
You can't not answer questions about things that you have done, as your potential future employer needs to have some way to evaluate your ability to work and solve problems based on your past experiences. However, you do need to be aware of material that is in some way sensitive and not violate any agreements that you have made.
A specific example from my past: I worked on software used to test an airborne ISR sensor system. During the course of my work, I typically used Java, Eclipse, ClearCase, ClearQuest, Apache XMLBeans, SOAP, and how I interfaced with a CORBA package. I don't get into specifics of what the SOAP messages were, with the IDL files looked like, what the format of the XML I was parsing is, or any algorithms that I saw or created. But I do talk about my workflow and processes with Eclipse, ClearCase, and ClearQuest, the fact that I had to learn about XMLBeans, SOAP, and CORBA since I had no prior experience, and so on. I also talked about my team experiences during that time frame, and my interactions with other engineers working on the same project.
Also, as a side note, the scenario that you describe is extremely unlikely. Any software used in a mission critical system should be well-vetted by tests to ensure that something like that can happen. If simply knowing what tools and technologies exist in a system gives an attacker the ability to compromise the system something is a little wrong there.